Наш 12 летний опыт работы с клиентами показывает, что даже при наличии хорошо разработанной функциональной ИТ-системы и действительно квалифицированных программистов, эта самая система может быть совершенно не описана, не структурирована и не документирована. А на вопрос — «А какой функциональностью обладает ваша система, как она работает, и где можно её изучить?» — ответить могут только специалисты, которые её разрабатывали. Конечно, если разрабатывали её они не так давно. В противном случае многие вещи просто сотрутся из памяти.
На наш взгляд, описание и документация — это фундамент построения ИТ-системы, который помогает избежать ситуаций, когда она становится «неуправляемым монстром». На практике мы уже сталкивались с такой проблемой — в конце концов ИТ-система перестаёт соответствовать реалиям бизнеса и вызывает необходимость нового проекта по приведению ее в порядок.
Для себя мы выработали некоторую модель описания ИТ-системы, которая должна довольно быстро сформировать представление — что есть в системе, что в ней уже работает, что не работает, какие в ней есть особенности, кто какими частями пользуется, кто за что отвечает.
Надеемся, она окажется полезной и для Вас.
Модель описания ИТ-системы
Рисунок 1. Модель описания ИТ-системы
1.Верхний уровень – это информационная база. Как правило, современные информационные системы даже для средних компаний реализуются набором информационных баз (это может быть ERP-система, система бухучёта, система зарплаты и управления персоналом, система для управления торговлей, система для управления складом и т.д.).
Есть мнение, что всё желательно сделать в одной базе. И мы его не разделяем. Верхний уровень деления на информационные базы позволяет упростить сопровождение информационной системы как раз за счёт того, что она разбивается на части с конкретным набором функций и операций.
2.Подсистема – это нечто крупное, то, что определяет собой относительно самодостаточную предметную область. Это может быть:
- подсистема управления транспортной логистикой,
- подсистема управления складской логистикой,
- подсистема приёма заказов,
- подсистема закупок и т.д.
Рисунок 2. Описание ИТ-системы на примере подсистемы транспортной логистики
3. В подсистеме есть функции. Если рассматривать как пример подсистему транспортной логистики, то в ней есть функции:
- формирование шаблона маршрута,
- формирование рейса на конкретный день,
- закрытие рейсов после того, как они выполнены,
- расчёт сдельной заработной платы водителя, на основании его результатов работы.
4. Операции находятся внутри функций. Операции — это составляющие элементы функции, каждая из которых подкреплена какой-то функциональностью в ИТ-системе.
Опять же, если вернуться к нашему примеру с транспортной логистикой и рассмотреть функцию формирования маршрутов движения транспорта на день, то операциями здесь будут:
- учёт текущей доступности транспортных средств,
- автоматическое распределение принятых заказов на машины в соответствии с шаблонами, которые были созданы в рамках другой функции,
- ручная корректировка загрузки транспортных средств с перераспределением заказов,
- печать маршрутного листа.
!!! Отдельно надо отметить, что уровни в описании ИТ-системы на разных этапах развития информационной системы могут меняться местами. То есть операции могут становиться функциями, функции могут становиться подсистемами.
Например, если у компании слабо развита транспортная логистика, то в какой-то момент, подсистема транспортной логистики может стать функцией в рамках подсистемы исполнения заказов покупателя. Получается, что в модели ИТ-системы есть подсистема исполнения заказов покупателя и есть функция транспортной логистики, так как она реализована в минимальной функциональности. А если транспортная логистика начинает расширяться и в ней повышается количество операций, которые агрегированы этой функцией, то уже логично выносить её в масштабы подсистемы.
Таким образом, уровни модели могут изменяться и определяться масштабностью той или иной подсистемы, функции, операции или базы.
Что даёт такое описание ИТ-системы?
- Целевой результат в проекте.
На начальном этапе построения ИТ- системы у нас появляется целевой результат в проекте. Мы точно знаем — к чему идти, какую функциональность мы должны реализовать с ИТ-системе.
Описание как раз помогает всем участникам проекта внедрения/развития ИТ-системы фиксировать результат его завершённости.
Мы получаем простой понятный и измеримый результат в проекте. Видим — какие функции и какие операции автоматизированы, а какие — нет.
- Основу для документирования системы.
На практике мы встречаем примеры, когда документация по проекту у клиента довольно полная, но при этом не структурирована, не цельна и описана не системно. К тому же она зачастую раскрывает только пользовательское поведение и не даёт ответов на вопросы об особенностях внутреннего устройства отдельных функций.
Модель описания ИТ-системы (Рисунок 1) как раз позволяет упорядочить и структурировать весь набор инструкции, которые есть по работе с системой. Как следствие, мы довольно быстро ориентируемся в документации и быстро находим всю необходимую нам информацию.
Если мы какую-то функцию или операцию изменяем, то уже точно знаем — какой блок документации нам нужно править.
- Упрощает передачу на сопровождение.
Любая система в процессе своего внедрения формирует понятный способ передачи на сопровождение. Конечно, при условии, что она описана по определённой структуре.
Если ИТ-система более-менее крупная, то она не передаётся на сопровождение целиком и за раз. Система запускается по операциям, по функциям, по подсистемам.
Как только какая-то из этих функций или подсистем запущена, у нас появляется возможность передать эти участки системы с понятным набором задач на сопровождение, тем самым упрощая его.
- Навигатор для развития системы.
У любой системы есть планы по её развитию. И это нормально — всегда хочется от системы получать большего.
// При этом у всех уровней (функций, операций, подсистем) есть статус — либо они находятся в статусе планирования, либо в разработке, либо в опытной промышленной эксплуатации, либо в промышленной эксплуатации.
Во-первых, сами уровни являются некоторыми навигаторами развития нашей системы.
Во-вторых, есть возможность оценивать текущее состояние системы и векторы её развития. Мы должны понимать — куда она развивается, в каком именно месте (какие подсистемы, функции, операции) и в каком состоянии развития находится.
- Снижает риски работоспособности системы и снижает зависимость от ИТ-исполнителей.
Когда вся информация об ИТ-системе сосредоточена в одном человеке, то это, как минимум, создаёт трудности для него самого. Он чувствует свою ответственность, не может болеть, уходить в отпуск, потому что никто кроме него не понимает — как работает система.
У самой компании появляется от этого исполнителя (а что делать, если этот сотрудник уволится?). Получается, что описание даёт доступ к информации и понимание об устройстве ИТ-системы всем заинтересованным лицам компании. При этом знания не сосредотачиваются в человеке.
Вместо заключения
Конечно, в небольшой статье мы не опишем все детали и особенности модели описания ИТ-системы.
У В компании у нас есть внутренние документы, регламентирующие описание ИТ-системы с более точными формулировками каждого уровня и с наличием примеров.
Готовы поделиться с вами этой документацией, если у вас есть интерес к структурированному описанию своей ИТ-системы.