Часто возникает задача регламентировать деятельность организации. При этом используются существующие формы документов - описания процессов, положения, регламенты, рабочие инструкции. Результат получается качественно разный и зависит от многих факторов. Я разберу одну из причин некачественного результата - неподходящий шаблон документа.
Обычно в той или иной вариации организация использует 3-4 уровневую структуру документов:
- Уровень общих описаний. Политики, положения, сквозные процессы уровня организации.
- Уровень регламентов. Достаточно детальное описание последовательности действий при выполнении работ, распределение ответственности.
- Рабочие инструкции. Детальные описания последовательности работ и распределение ответственности.
Уровни 1 и 2 могут быть разбиты на 2 подуровня.
В чем подвох? Для простоты буду приводить примеры конкретных бизнес-процессов розничной организации.
Ловушка 1. Целевая система или обеспечивающая?
Сравните "Регламент обслуживания покупателей в кассовой зоне" и "Регламент закупки и технического обслуживания оборудования кассового узла". Видя слово регламент в названии, разработчик документа часто использует одну и ту же форму. Где ошибка?
Обслуживание покупателей относится к целевой системе, это определение системы. Скорее всего, этот документ будет содержать как требования, так и архитектурные и неархитектурные решения. В нем должны явно указываться стейкхолдеры данной части системы и их интересы. Должен быть явно указан использованный при описании частный метод описания, а модели четко отделены друг от друга в тексте документа. Для каждого требования должен быть приведен метод проверки, например, аудит или измерение KPI.
Техническое обслуживание оборудование кассового узла описывает обеспечивающую систему. Этот документ будет содержать в себе часть модели жизненного цикла и организационной модели, ср. системную схему предприятия. Здесь должны явно быть указаны практики и их элементы - дисциплины и технологии. Например, используется ли превентивное ТО или ТО по инциденту? Это принципиально разные подходы и технологии. Напоминаю, что под определение технологий попадают не только ИТ-системы, поддерживающие процесс, но и формы документов, чек-листы и т.п.
Вывод. Попытки совместить в одной форме два принципиально разных описания приведут либо к очень тяжелому описанию, в котором какие-то разделы будет непонятно чем заполнять и непонятно кому эти разделы читать, либо к пропуску значимой информации.
Ловушка 2. Интерфейсы и интерфейсные модели.
Инструкция по приемке товара на склад. Коротенькая, пара страниц максимум. Кто что делает, что проверяет. Это процесс-интерфейсный модель, если поставить трекер или оформлять приемки по файлам папочек, будет кейс-интерфейсный модуль. Здесь важны стабильность, надежность, воспроизводимость и низкая стоимость операций. Часто в документе пропускают порядок постоянного улучшения процесса. А зачастую нет и самого описания интерфейса, только "кладовщик принял ТТН, принес ТОРГ-12 начальнику склада, подписал и т.п.". Нужно описать между какими подсистемами интерфейс, описание интерфейса, режимы работы. См.? например, Бакмана.
Вывод. Попытки использовать форму стандартной рабочей инструкции по отношению к интерфейсам приводят к пропуску ключевых элементов. Часто не указывают, какие ресурсы выделены на интерфейс, какие вариации допустимы и уж никогда не приводится обоснование выбора дизайна интерфейса. Просто так уж сложилось.
Есть и множество других ошибок при разработке бизнес документации. Изучайте системное мышление, пишите качественные документы, одного владения инфостилем недостаточно.
Силы зла побеждают. У них даже картинки смешнее.
