Автоматизированный беспорядок не становится автоматизированным порядком! Поэтому все начинается с того, что мы описываем процессы и выделяем бизнес-требования. Давайте на примере покажем, как это выглядит.
Любая компания — это набор повторяющихся процессов. То насколько логично они выделены будет напрямую зависеть качество продукта или услуг в вашей компании. Этот принцип определен в ISO серии 9000.
Понятное описание процессов позволяет нам
- делегировать ответственность: вот процессы, где ты ответственный, вот описание как их выполнять
- обучение сотрудников
- развивать организационную структуру: появилась новая должность – вот список ее процессов
- формировать KPI: вот описание процесса, а вот показатели и сам процесс отвечает на вопрос как их отслеживать.
Сделать такое описание в Word или Excel невозможно, для этого нужна WiKi-система, которая позволяет совместно редактировать данные, отслеживать изменения, контролировать старые и новые версии данных, группировать и фильтровать материал, наличие ссылочной избавляет нас от copy/paste… Мы выбираем для этих целей Confluence.
Дерево процессов может быть сгруппировано так как вам удобно:
Или так
Гораздо важнее то, как выделены и описаны процессы. Для описания мы применяем нотацию BPMN. При этом каждый шаг – это действие на схеме, которое имеет текстовое и графическое описание. Шаг заменяет инструкцию. Важно не нагромождать процессы, а оставлять их легкими для восприятия, и чтобы они однозначно определяли ответственного.
Документы на схеме отражают реальные документы или объекты в системе, которые рождаются при выполнении шага. Цвет документов может определять систему, в которой этот документ создается. Связь процессов, можно отразить на общей верхнеуровневой схеме, ссылкой на Предшествующие процессы в описание процесса, а также графически на самой схеме.
Так как мы работаем в умной WiKi-системе, мы можем на одной странице собрать список всех процессов по Ответственному. Вышел новый сотрудник – вот список твоих процессов, в каждом есть подробное описание твоих инструкций и целей.
Теперь посмотрим как выглядит шаг:
Здесь описание может быть текстовым, может быть графическим или с видео – все как вам хочется. Важно, что все изменения отслеживаются и поэтому любой сотрудник может сам вносить правки (ведь инструкция должна быть живой), а вы можете их отслеживать и восстановить любые данные:
Каждый шаг связан с требованиями. Все требования описывают функционал информационных систем (далее ИС), то есть это набор бизнес-функций, которые реализованы или будут реализованы в ИС. Здесь мы не привязываемся к тому является это стандартным функционалом или доработкой. Такой подход позволяет очень легко сопровождать систему – мы всегда помним, что и где настроено, для чего (так как есть связь с шагом и бизнес-процессом) и описание того, как это реализовано.
Также требования имеют оценку и управление списком требований – это управление бюджетом на внедрение или развитие ИС. Вы сами можете решить, что для вас важно, а что можно не делать и сократить таким образом бюджет.
Требования, которые имеют тип «Интеграционное» отражают потоки данные, и лежат в основе архитектуры.
По такой технологии мы сделали проектирование для клиента ГЕРОФАРМА. Это необходимая документация для начала внедрения, но это не просто документ «в стол». Проектирование – это тоже продукт, который может использоваться клиентом для сертификации ISO, для обучения сотрудников, для внутреннего ИТ-департамента.
