Gap анализ при внедрении типовых решений
•Als PPTX, PDF herunterladen•
0 gefällt mir•886 views
Доклад Николая Соколовскогона конференции Analyst Days-6 www.analystdays.com
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von SQALab
Mehr von SQALab (20)
Gap анализ при внедрении типовых решений
- 1. Gap-анализ требований к типовым решениям внедряемых систем Николай Соколовский Бизнес аналитик, DataArt 2017
- 2. Что такое Gap-анализ • Gap-анализ – метод выявления и описания требований к программному продукту.
- 3. Когда это имеет смысл? Если Ваш продукт/компонент : 1. имеет множество настроек полностью меняющих логику работы приложения 2. постоянно внедряется у однотипных клиентов 3. решает в целом схожие, но различные в деталях проблемы
- 4. Кейс Группа процессов Примеры процессов Сбор информации о пациенте Регистрация пациента в приемном отделении Уточнение данных для неизвестного Счета Выставление счетов по ОМС Выставление счетов по ДМС Врачебные процессы Первичный осмотр Лаборатория Забор биоматериала Сортировка и маркировка проб Материальный учет Производство медикаментов
- 5. Как построить gap-анализ? Вам потребуются примеры процессов и внедрения системы (или очень сильная экспертиза в предметке). После набора примеров: 1. Найти повторяющиеся процессы 2. Найти повторяющиеся части этих процессов 3. Создать мастер-процесс 4. Описать «Желтые» варианты для каждого мастер-процесса. 5. Описать пост и пред условия для каждого мастер процесса 6. Описать связи между процессами 7. ... 8. Profit!
- 6. Что за «желтые» варианты? Типы отклонений от процесса: 1. Зеленые = все хорошо (в идеале это ваш мастер-процесс) 2. Желтые = что-то идет не как обычно, но мы с этим встречались. 3. Красные = что-то совершенно новое.
- 7. Пример: мастер-процесс регистрации в приемном отделении Business Process Base Green Variants Приемноеотделение Мед.сестраприемного отделения Врач Запись в журнале приемного отделения Заполнение титульной формы истории болезни Подписание согласий (персональные данные, мед.вмешательство) Осмотр пациента Принятие медицинского решения по пациенту Госпитализация Амбулаторная выписка Отказ в госпитализации Поступление пациента
- 8. Пример: желтый вариант регистрации в приемном отделении
- 9. Пример: красный вариант регистрации в приемном отделенииBusiness Process RED Приемноеотделение Мед.сестраприемногоотделенияВрач Запись в журнале приемного отделения Заполнение титульной формы истории болезни Подписание согласий (персональные данные, мед.вмешательство) Осмотр пациента Принятие медицинского решения по пациенту Госпитализация Амбулаторная выписка Отказ в госпитализации Поступление пациента Укус клеща? Забор биоматериала Вакцинация Заполнение сокращенной формы истории болезни Выписка NO
- 10. Пример: пост / пред условия Процесс предполагает что: • Из больницы нет побегов, а если таковой случается, ИБ закрывается и при возвращении пациента открывается как новая • При подсчете койко-дней время проведенной в приемное отделение не учитывается
- 11. Пример: наполнение титульного листа истории болезни в разных вариантах Зеленый вариант Желтый вариант Красный вариант Дата-время поступления ФИО пациента Дата рождения ФИО врача Предварительный диагноз Диагноз приемного отделения …. Дата-время поступления ФИО пациента Дата рождения Номер направления Диагноз направления Диагноз приемного отделения Диагноз приемного отделения …. Дата-время поступления ФИО пациента Отметка “не известный” Описание неизвестного Номер машины скорой медицинской помощи Диагноз скорой медицинской помощи Дата рождения ФИО врача Диагноз приемного отделения ….
- 12. Пример: связанные требования Для каждого мастер процесса нужно запросить: 1. Типы документов удостоверяющих личность (паспорт, дипломатический паспорт и т.п.) 2. Социальная категория (работающий, инвалид I гр. и т.п.) 3. Список врачебного персонала 4. Список отделений больницы 5. Уточненную международную классификацию болезней 10- го пересмотра 6. ….
- 13. Что мы получаем? 1. Уменьшение времени на выявление требований и подготовку/верификацию решения. 2. Точные estimate задач и проекта 3. Команды могут сделать шаблоны 4. Опросники для клиента 5. Проще обосновать цену.
- 14. Почему это не серебряная пуля? 1. Требует больших стартовых инвестиций 2. Требует понимания работы аналитика от менеджмента 3. Может оказаться что у клиента очень большая специфика 4. Могут встретиться узко-специфичные процессы 5. Требуется регулярные пересмотры репозитория мастер- процессов и их вариантов.
- 15. Как организовать репозиторий? • Один мастер-процесс – один каталог • Все варианты процесса хранятся в том же каталоге, что и основной • Описания условий, связанных требований хранятся в том же каталоге (желательно в одном файле вместе с описанием матер-процесса) • Репозиторий хранится на сервере и регулярно бекапируется • Написана инструкция как им пользоваться • За обновление репозитория отвечает конкретный человек
- 16. Спасибо за внимание! E-mail: Nikolay.Sokolovskiy@dataart.com Skype: n.sokolovskij
Hinweis der Redaktion
- Gap analysis is method which shows you deference between ideal model and specific object. Also it shows you some steps to achieve the purpose state. In BA it means that you have some ideal BPs and you compare with specific BPs of client. After that you find deferences and you planning your steps to achieve the result.
- Well in IT the target of project is a working system. So I suppose that gap-analysis is better when: You have big application, which you customize for client. Customization conteins a lot of deffrent options. Your appliaction suppots a lot of different bissiness processes. you need to decide which BPs client needs. BPs of clients are very simmilar in general, but diferent in details.
- Shot about my experience. Well, I have worked in medical software development for 8 years. Last 2 years I worked like BA for product company. I wrote technical projects for deploy of our system for different clients. We supported this groups of BPs. you can see it on my slide. For sure this is not a complete list, just a brief
- You have to split all variation of each process to three zones: Green. It is "Ok". This is your master-process. May be you have little deviations, but it is still well-know process and these deviations are not able to increase time and cost of project. Beside the risks of these deviations are small or absent. Yellow. This is the danger zone. You still know about these variations. However implementation of them able to increase cost, time and risks. You must alarm your PM and team about it. You must be careful with these deviations because they may quickly move to red zone. Red. It is your personal "doom-day". You see this variant for first time. You know nothing about it. It is not bad itself. However The devil is in details. The most of processes are connected to each other. And if you find the one "red" process you must check all your description of processes for the client. It may be big job.
- This is one of usual process for Russion hospitals. I use high-level scheme because I don’t want show to you a lot of specific details of subject domain. This is emergency room of hospital which doesn’t attendance of Emergency Call service. It is simple process. The nurse is fill papers, doctor exanimate of patient and make decision.
- And now I show you to yellow variants. It is first. This hospital takes patients only if they have prescription, because it is psychiatrics clinic for border-line mental illness. And if patient has appointment card, the hospital guarantees the treatment.
- So it is red. You can see parallel branch of nurse. And this branch cost for us about 50% of initial cost of contract. We need serious development. Why? Because it is involve medical statistic of hospital. And many algorithms of calculation of bed-days were change. And short form of history of deases reqiered the new mode of work of our software.
- Pre and post condition are very important. They are told us when our process truthly.
- There is cases of different package of data. The red color significes a delta between green and yellow variations for one forms.
- All position of this list must be full. You can check youselft with help this list.
- Decrease time of elicitation and making solution time. Once I could make technical project for 4 hours. Usually this work requires 80 hours or more. Transparent for planning time of project. Your team is able to make "templates" for realization of green and (if they have a lot of time) yellow variants of processes. You can make questionnaire for your client. For example you can ask to him all data for DB in one email. Your sales manager can build price. Because you know your processes in detail, you (or your PM or team) can estimate it. and this estimation will not changed.
- this is an expensive tool. Actually in my previous company we didn't build full description of all green processes. We didn't have enough time. Why? Well we have three reason: Big volume of work itself. And it is complicate work. If you make mistake with general part, your real green processes will not be describe. they will be in yellow and red zones. It means that you will do big work to describe false-green variants, after you describe some amount of clients with a lot of "yellow" and "red" variants, only after (may be) you will see that something is wrong. And you will begin all work again. Change of application. Your product changes all time. And new functionality must be included into processes descriptions Change of business. Processes are constantly changing So you have to change your idea about green and yellow variants. Sometimes you will find the new process and understand that is "green", but you have not seen it before. Your PM may deside that company doesn't need BA for description green variants. And your task will be to explane all about updates and how this tool works. Sometimes it is impossible. And you will see how your work are dying. You always have to update you descriptions. If you loose changes then you start again, because you don't trust your green variation any more.