Мастерская бизнес-анализа

Бизнес-анализ -Сангвис –АСУ Пеликан Структура Базы данных

15.02.2011 at 20:00 1 комментарий

Часть первая – наше техническое задание Продолжение

Итак, август 1989 года, условия начала нового проекта:

1. Новый для нас объект автоматизации, и работали мы как внешние разработчики
2. Полное отсутствие аналогов, публикаций, типовых решений – чего-бы то ни было, поэтому естественно, что это была заказная индивидуальная разработка
3. Полное отсутствие использования средств автоматизации на объекте и какого-либо опыта у пользователей
4. Обязательность использования стандартов во всех отраслях деятельности, где они существовали, и при создании информационных технологий, частности
5. Система должна была быть разработана для всей организации, а не для какого-то отдельного подразделения (со временем масштаб организации еще и вырос значительно).
6. Инициатором разработки АС являлось высшее руководство организации.

В соответствии с действовашими ГОСТами мы погрузили в первый проект и своего рода НИР, и обследование и описание имеющегося состояния, и обоснование необходимости автоматизации. А результирующим документом стало само «Техническое задание».
Позже, работая начальником отдела бизнес-анализа, я требовала от аналитиков подготовки отдельных документов: отчета об обследовании и собственно Технического задания. Это было связано с тем, что источником информации при обследовании были конечные пользователи – исполнители разного уровня (специалисты, руководители групп и отделов), а принятие решение осуществлялось специалистами более высокого уровня – руководителем организации и его заместителями. Поэтому выводы обследования, правильность трактовки фактов, анкет, бесед, было необходимо закрепить именно у руководителей, и поэтому формировался отчет.
Мне представляется, что подробный и выверенный, согласованный со знающими экспертами, отчет об обследовании, очень полезен в работе и проектировщикам (на самых разных этапах).

Обследование

В Сангвисе мы отдельный отчет не делали, так как и основным источником информации и принимающим решение человеком было одно и тоже лицо. Конечно, мы обследовали «как есть» на практически всех рабочих местах, познакомились с большим количеством людей, но подавляющее число вопросов, которые сопутствуют обследованию, задавались руководителю, и при принятии решения ориентировались только на его мнение.
Мы изучили очень тщательно всю имеющуюся нормативную документацию. Ее было много, и, что нам очень помогло, значительная часть документации носила название «Инструкция….». То есть на большинство процессов были документы, в которых описывалось не только ЧТО, но и КАК надо делать.
Процессы заготовки и переработки крови имеют выраженный характер «производственной технологии», но и обладают массой  особенностей, связанных и с тем, что очень специфическое «сырье» — кровь донора, которая находится в человеческом теле, и с особенностями конечного продукта, и с особенностями кадров – специалисты практически все по образованию врачи.
Одной из основных задач обследования для нас было структуризовать всю деятельность и информацию о ней. Сразу оговорюсь – на сегодняшнем языке это наверное бы звучало: «построить исходную модель предметной области». Тогда понятие «моделирование» тоже уже было, и широко использовалось. Но мне всегда представлялось, что лучше применять понятия и термины, которые разработчикам и пользователям одинаково понятны до проекта. Конечно, так получалось не всегда. Что касается структуризации, то для нас важно было именно это, поэтому так и определили задачу. Тем более, что построение организации службы крови и технология работы приводит к некому естественному определению структуры. И именно поэтому, многие информационные системы (теперь-то они конечно есть) выглядят на первый взгляд почти одинаковыми. В каждой системе основными элементами структуры являются “ДОНОРЫ”, “ЗАГОТОВКА”, “ТЕСТИРОВАНИЕ”, “ЭКСПЕДИЦИЯ”, “БУХГАЛТЕРИЯ”.
И на первом этапе работы был велик соблазн работать последовательно – взять сначала какой-то явно видный структурный элемент, и сделать его, а потом (если получится хорошо) пойти дальше. И многие в то время (когда в качестве техники в медицине были в основном локальные персоналки) именно так и делали.

Для нас – и Заказчика, и нашей команды, важно было с одной стороны, выделить элементы структуры, разделить объект на части, но с другой стороны, было важно выявить и не упустить в дальнейшем, связи, построить единый технологический процесс, который только и приводит к «правильному результату» — дает возможность разработать систему автоматизации не «для галочки», а реально помогающую делу.
И выполяли мы эту структуризацию именно на этапе обследования, потому что в существовавших документах не было построено никаких структур, для вновь пришедшего человека это была просто каша. И именно анализ на этапе обследования позволил понять почему это так – было очень много связей, пересечений.
Попробую на примере: очень логично выделялся элемент структуры «Работа с донорами», и другой элемент – «Тестирование». Но! У донора в момент осмотра у врача До кроводачи – при принятии сиюминутного решения: отправить человека на следующий этап технологического процесса или отвести от кроводачи и прекратить работу с этим человеком – делается анализ на гемоглобин. А это значит, что небольшая часть «тестирования» находится внутри «работы с донорами».
Это проблема не уникальна, она есть во многих предметных областях, но ее надо было не только увидеть (не фокус – все работники СПК об этом знали), но и зафиксировать так, чтобы потом при проектировании логично все выстроить.

Техническое задание

Разработано для того, чтобы зафиксировать совместно принимаемые решения как внутри команды разработчиков, так и согласовать однозначное их понимание разработчиками и пользователями.

При его подготовке по согласованию с Заказчиком были приняты следующие исходные решения:
1.Информационная технология с первых шагов ее разработки будет рассматриваться как комплексная автоматизированная СИСТЕМА, охватывающая ВСЕ информационные объекты и процессы.
2. Будут использоваться и закладываться наиболее современные и перспективные технологии и решения, а не самые дешевые
3.Разработка и внедрение отдельных частей системы будет проводиться поэтапно, очередность этапов диктовалась следующими обстоятельствами:

• Технологической цепочкой (сначала — работа с донорами, уже затем заготовка крови, тестирование и т.д.)
•  Возможностью локальной разработки и внедрения (так в первоочередные попал АРМ «Экспедиция» — важнейший участок, не очень сложный для автоматизации – объект типа «склад», но стоящий в конце технологической цепочки заготовки продуктов крови)

4. Приоритетным для разработки является поддержка автоматизацией основного технологического процесса, а НЕ управленческих функций (как это было принято в то время, особенно в бюджетной сфере – на первом месте бухгалтерия).

Принципы эти серьезно противоречат друг другу, поэтому были оговорены, зафиксированы и свято выполнялись следующие договоренности:
1. Разработанные программые куски будут первоначально тестироваться и сразу предлагаться к внедрению до окончательного завершения их разработки (то есть часть доработок будет идти параллельно с внедрением). То есть, пользователи были настроены, подготовлены на первом этапе к тому, что программы еще сырые, могут быть сбои и ошибки, и задача пользователей помочь в отладке и доработке. А программисты были ориентированы на то, что после начала внедрения будут еще многочисленные доработки и переработки.
2. Отдел АСУ с самого начала становится буфером между разработчиками и пользователями, и разрешает все проблемы, возикающие в процессе внедрения. Более того, прямо в системе были придуманы (именно на начальном этапе – в ТЗ) специальные процедуры, позволяющие специалистам отдела АСУ и обязывающие их проводить тотальный контроль работы информационной ситемы в целом и отдельных пользователей.
3. Первая версия Системы разрабатывается в значительной степени как «подстрочник» (это метафора Заказчика по аналогии с работой переводчика) – реализация действующей технологии с использованием компьютера – для обучения и приучения пользователей. И лишь последующие версии разрабатываются с изменением технологий и более значительным задействованием возможностей автоматизации.
За этими словами стояло общее понимание того, что делать мы все будем не по одному разу (а первая версия вообще «в корзину»), и поэтому никого не смущали постоянные изменения.
Хотя уж совсем «в корзину» ничего не делалось. На первых версиях были созданы базы данных (их содержимое), а это уже большая работа, а также прошло первичное обучение пользователей.

В первом техзадании был прописан такой набор АРМов: «Регистратура донорского отдела», «Врач-терапевт», «Лаборатория первичного контроля», «Экспедиция». И примерно в такой последовательности эти АРМы и проектировались и внедрялись.
Затем было сделано 2 дополнения: одно официальное – по АРМ «Операционная», а второе даже официально не оформлялось – по АРМ «Лаборатории тестирования на инфекции».
Все последующие разработки выполнялись без оформления дополнений к Техзаданию – уже потребности не было. Делались постановки задач, программирование и документация. Кроме того, детально прорабатывались календарные планы работы внешних разработчиков.

О чем не писалось в публикациях

Что я считаю изюминкой того решения, которое было придумано в 1989г, и благодаря которому нам удавалось справляться с такими проблемами как частые изменения и большой объем информации.
Это структура базы данных. Сразу скажу – никакой теорией это решение не было подкреплено, просто из опыта, анализа задачи и возможностей FOXPRO мне оно показалось разумным, а коллеги поддержали.
В основу БД был положен такой подход, при котором создаются:
1. Картотеки (то есть перечни объектов), с характеристиками, присущими объектам (для картотеки доноров – ФИО, паспорт, адрес..). То есть все эти данные могут меняться, но это условно-постоянная информация.
2. Данные, описывающие поведение объектов картотеки – наиболее яркий пример – для каждого донора – в файле «кровдачи» хранятся записи по каждой кроводаче, которых у одного донора как правило много.
Эти файлы базы данных хранимые – информация в них накапливается, копируется, в последующем используется как для функционирования системы, так и для анализа.

Непосредственная ежедневная работа в Системе осуществляется с оперативным файлом. Его нельзя назвать временным – если служба крови работает, то какие-то данные там есть всегда. А вот конкретные данные – о донорах, кроводачах, полученных продуктах, тестах и т.д – хранятся в этом файле временно. Информация о конкретном доноре заносится в этот файл в тот момент, когда врач на осмотре донора принимает решение о кроводаче (а не отводе), «обрастает» данными в течение нескольких дней, пока идет обследование, и удаляется из оперативного файла в результате специальной процедуры, названной «реорганизация», осуществляемой администратором – работником отдела АСУ. При этом данные из оперативного файла помещаются в картотеки.

Так удалось решить сразу несколько задач:

• сделать достаточно быстрой работу многих программ (работающих или только с оперативным файлом, или с ограниченным количеством картотек) в условиях использования «слабой» техники
•  обеспечить  сохранность данных в картотеках, их целостность
•  значительную часть изменений вносить в БД именно в этом оперативном файле – при частых изменениях интерфейса, расчетов и т.д
•  обеспечить контроль прохождения всех этапов технологического процесса и информирование пользователей о выявляемых нарушениях
• обеспечить контроль и анализ работы отдельных пользователей

Entry filed under: Мемуары Сангвис, Методы и технологии анализа, Пользователь и ИТ-специалист. Tags: Ит-Пеликан, бизнес-анализ.