Как описать свою ИТ-систему. Советы бывалого автоматизатора

7 минут чтения

Как описать свою ИТ-систему. Советы бывалого автоматизатора

Наш 12 летний опыт работы с клиентами показывает, что даже при наличии хорошо разработанной функциональной ИТ-системы и действительно квалифицированных программистов, эта самая система может быть совершенно не описана, не структурирована и не документирована. А на вопрос — «А какой функциональностью обладает ваша система, как она работает, и где можно её изучить?» —  ответить могут только специалисты, которые её разрабатывали. Конечно, если разрабатывали её они не так давно. В противном случае многие вещи просто сотрутся из памяти.

На наш взгляд, описание и документация — это фундамент построения ИТ-системы, который помогает избежать ситуаций, когда она становится «неуправляемым монстром».  На практике мы уже сталкивались с такой проблемой — в конце концов ИТ-система перестаёт соответствовать реалиям бизнеса и вызывает необходимость нового проекта по приведению ее в порядок.

Для себя мы выработали некоторую модель описания ИТ-системы, которая должна довольно быстро сформировать представление — что есть в системе, что в ней уже работает, что не работает, какие в ней есть особенности, кто какими частями пользуется, кто за что отвечает.

Надеемся, она окажется полезной и для Вас.


Модель описания ИТ-системы

Модель описания ИТ-системы

Рисунок 1. Модель описания ИТ-системы

1.Верхний уровень – это информационная база. Как правило, современные информационные системы даже для средних компаний реализуются набором информационных баз (это может быть ERP-система, система бухучёта, система зарплаты и управления персоналом, система для управления торговлей, система для управления складом и т.д.).

Есть мнение, что всё желательно сделать в одной базе. И мы его не разделяем. Верхний уровень деления на информационные базы позволяет упростить сопровождение информационной системы как раз за счёт того, что она разбивается на части с конкретным набором функций и операций.

2.Подсистема – это нечто крупное, то, что определяет собой относительно самодостаточную предметную область. Это может быть:

  • подсистема управления транспортной логистикой,
  • подсистема управления складской логистикой,
  • подсистема приёма заказов,
  • подсистема закупок и т.д.

Описание ИТ-системы на примере подсистемы транспортной логистики

Рисунок 2. Описание ИТ-системы на примере подсистемы транспортной логистики

3. В подсистеме есть функции. Если рассматривать как пример подсистему транспортной логистики, то в ней есть функции:

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

4. Операции находятся внутри функций. Операции — это составляющие элементы функции, каждая из которых подкреплена какой-то функциональностью в ИТ-системе.

Опять же, если вернуться к нашему примеру с транспортной логистикой и рассмотреть функцию формирования маршрутов движения транспорта на день, то операциями здесь будут:

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

!!! Отдельно надо отметить, что уровни в описании ИТ-системы на разных этапах развития информационной системы могут меняться местами. То есть операции могут становиться функциями, функции могут становиться подсистемами.

Например, если у компании слабо развита транспортная логистика, то в какой-то момент, подсистема транспортной логистики может стать функцией в рамках подсистемы исполнения заказов покупателя. Получается, что в модели ИТ-системы есть подсистема исполнения заказов покупателя и есть функция транспортной логистики, так как она реализована в минимальной функциональности. А если транспортная логистика начинает расширяться и в ней повышается количество операций, которые агрегированы этой функцией, то уже логично выносить её в масштабы подсистемы.

Таким образом, уровни модели могут изменяться и определяться масштабностью той или иной подсистемы, функции, операции или базы.


Что даёт такое описание ИТ-системы?

  1. Целевой результат в проекте.

Целевой результат в проекте

На начальном этапе построения ИТ- системы у нас появляется целевой результат в проекте. Мы точно знаем — к чему идти, какую функциональность мы должны реализовать с ИТ-системе.

Описание как раз помогает всем участникам проекта внедрения/развития ИТ-системы фиксировать результат его завершённости.

Мы получаем простой понятный и измеримый результат в проекте. Видим — какие функции и какие операции автоматизированы, а какие — нет.

  1. Основу для документирования системы.

Основу для документирования системы

На практике мы встречаем примеры, когда документация по проекту у клиента довольно полная, но при этом не структурирована, не цельна и описана не системно. К тому же она зачастую раскрывает только пользовательское поведение и не даёт ответов на вопросы об особенностях внутреннего устройства отдельных функций.

Модель описания ИТ-системы (Рисунок 1) как раз позволяет упорядочить и структурировать весь набор инструкции, которые есть по работе с системой. Как следствие, мы довольно быстро ориентируемся в документации и быстро находим всю необходимую нам информацию.

Если мы какую-то функцию или операцию изменяем, то уже точно знаем — какой блок документации нам нужно править.

  1. Упрощает передачу на сопровождение.

Упрощает передачу на сопровождение

Любая система в процессе своего внедрения формирует понятный способ передачи на сопровождение. Конечно, при условии, что она описана по определённой структуре.

Если ИТ-система более-менее крупная, то она не передаётся на сопровождение целиком и за раз. Система запускается по операциям, по функциям, по подсистемам.

Как только какая-то из этих функций или подсистем запущена, у нас появляется возможность передать эти участки системы с понятным набором задач на сопровождение, тем самым упрощая его.

  1. Навигатор для развития системы.

Навигатор для развития системы

У любой системы есть планы по её развитию. И это нормально — всегда хочется от системы получать большего.

// При этом у всех уровней (функций, операций, подсистем) есть статус — либо они находятся в статусе планирования, либо в разработке, либо в опытной промышленной эксплуатации, либо в промышленной эксплуатации.

Во-первых, сами уровни являются некоторыми навигаторами развития нашей системы.

Во-вторых, есть возможность оценивать текущее состояние системы и векторы её развития. Мы должны понимать — куда она развивается, в каком именно месте (какие подсистемы, функции, операции) и в каком состоянии развития находится.

  1. Снижает риски работоспособности системы и снижает зависимость от ИТ-исполнителей.

Снижает риски работоспособности системы и снижает зависимость от ИТ-исполнителей

Когда вся информация об ИТ-системе сосредоточена в одном человеке, то это, как минимум, создаёт трудности для него самого. Он чувствует свою ответственность, не может болеть, уходить в отпуск, потому что никто кроме него не понимает — как работает система.

У самой компании появляется от этого исполнителя (а что делать, если этот сотрудник уволится?). Получается, что описание даёт доступ к информации и понимание об устройстве ИТ-системы всем заинтересованным лицам компании. При этом знания не сосредотачиваются в человеке.


Вместо заключения


Конечно, в небольшой статье мы не опишем все детали и особенности модели описания ИТ-системы.

У В компании у нас есть внутренние документы, регламентирующие описание ИТ-системы с более точными формулировками каждого уровня и с наличием примеров.

Готовы поделиться с вами этой документацией, если у вас есть интерес к структурированному описанию своей ИТ-системы.

0 0 votes
Рейтинг статьи
guest
0 Комментарий
Inline Feedbacks
View all comments
Связаться с нами

 

×
Copy link