Подготовка предприятия к цифровой трансформации
Об этой книге
Методика предлагает практический маршрут проектирования деятельности предприятия до настройки, доработки или развития ERP-системы. Читатель проходит путь от первичного обследования и выделения бизнес-предметов до процессов, процедур, учётного слоя, нормативно-параметрической архитектуры и проверяемой проекции на 1С:ERP.
В центре подхода — управляемая сущность и её жизненный цикл. Методика показывает, как не подменять деятельность документами и диаграммами, как связать процессы с аналитиками, справчниками, параметрами, реквизитами, статусами, ролями, отчётами и тестами, а также как провести обратную проверку полноты проектного решения.
Издание адресовано собственникам и руководителям предприятий, руководителям ERP-проектов, бизнес-архитекторам, аналитикам, консультантам 1С и владельцам процессов. Его можно использовать как рабочее руководство, основу проектного практикума и средство самопроверки готовности модели к автоматизации.
Содержание
Как пользоваться методикой 6
1. Почему автоматизацию нельзя начинать с диаграммы 6
Минимальная самопроверка исходной схемы 8
2. Как устроена правильная карта проекта 8
Что является GAP 9
3. Первый уровень: предварительное исследование и первичная инвентаризация 10
3.1. Организационное дерево и подобъекты 11
3.2. Физическая топология 11
3.3. Матрица применимости предметных областей 11
3.4. Инвентаризация информационных систем 11
3.5. Правило «предоставить или надиктовать» 11
Результат первого уровня 12
4. Второй уровень: специализированные вопросники 12
4.1. Паспорт вопроса 12
4.2. Основные классы специализированных вопросов 13
4.3. Как вести противоречивые ответы 13
Фрагмент специализированного вопросника по ТОиР 13
5. Третий уровень: бизнес-предмет и его таксономический паспорт 14
5.1. Минимальный состав паспорта 14
5.2. Состояния и события 15
5.3. Носитель не равен предмету 15
5.4. Процессные роли предмета 15
5.5. Когда кандидат не становится предметом 16
6. Четвёртый уровень: от бизнес-предметов к процессам 16
6.1. Как определить границу 17
6.2. Когда один «большой процесс» нужно разрезать 17
6.3. Домашняя область и соседние области 18
6.4. Связка процессов и направление деятельности 18
6.5. Паспорт процесса 18
7. Пятый уровень: процедуры, Áкторы и управленческие ракурсы 18
7.1. Три последовательных представления 19
7.2. Как встраивается СМК 19
7.3. Как встраиваются безопасность и регулирование 19
8. Шестой уровень: учётный и финансовый слой 19
8.1. Хозяйственный факт не равен проводке 20
8.2. Вопросы учётного ракурса 20
8.3. Финансовое обеспечение как соседний предметный контур 20
9. Седьмой уровень: нормативно-параметрическая архитектура ERP (NPA) 20
9.1. Почему NPA нельзя растворить в процессной или учётной модели 21
9.2. Входы и выходы адаптационного решения 22
9.3. Параметры и функциональные опции 22
9.4. Справочники, классификаторы и аналитические измерения 23
9.5. Типовые и дополнительные реквизиты 23
9.6. Статусные модели, роли и права доступа 24
9.7. Четыре независимых класса обязательности реквизита 24
9.8. Типовое решение как рекомендуемая отправная точка 24
9.9. Обратная проверка полноты от требуемого отчёта 25
9.10. Универсальная возможность и проектное решение 25
9.11. Минимальный маршрут NPA-проверки одной процедуры 26
10. Восьмой уровень: проекция на 1С:ERP и смежные системы 26
10.1. Что может быть носителем в 1С:ERP 27
10.2. Три класса fit-gap решений 27
10.3. Почему нельзя начинать с перечня функций 1С 28
10.4. Нетиповые механизмы и миграция 28
10.5. Тестирование как продолжение модели 28
11. Сквозной пример: PO-08.01 «Управление ремонтом и техническим обслуживанием оборудования» 28
11.1. Что устанавливает первичное обследование 30
11.2. Как появляется предмет «потребность в ТОиР» 30
11.3. Где заканчивается процесс 30
11.4. Окружение процесса 30
11.5. Адаптационный и проекционный эскиз для 1С:ERP 31
11.6. Что проверяется тестом 31
12. Контрастные примеры: транспортная логистика и НИОКР 31
12.1. Транспортная логистика 31
12.2. НИОКР и переход к серии 32
Общий вывод двух примеров 32
13. Что должно быть готово до начала автоматизации 32
13.1. Минимальный проектный пакет 33
13.2. Критерии готовности 33
13.3. Кто может выполнять автоматизацию 34
14. Где заканчивается эта методика 34
Приложение А. Минимальный первичный вопросник 35
Приложение Б. Шаблон минимального паспорта бизнес-предмета 35
Приложение В. Самопроверка готовности модели 36
Приложение Г. Программа вебинара-практикума 37
Блок 1. Диагностика плоской схемы — 20 минут 37
Блок 2. Извлечение бизнес-предметов — 25 минут 37
Блок 3. Один процесс — один драйвер — 25 минут 37
Блок 4. Окружение и соседние области — 20 минут 37
Блок 5. NPA-карта и проекция на 1С:ERP — 20 минут 37
Блок 6. Следующий шаг — 10 минут 37
Приложение Д. Карточка fit-gap решения 37
Пример карточки по потребности в ТОиР 38
Приложение Е. Протокол интервью и обработки материалов 39
До интервью 39
Во время интервью 39
После интервью 39
Карточка переданного материала 39
Приложение Ж. Диагностика типовых антипаттернов 39
1. «У нас всё начинается с заявки» 39
2. «Мы нарисуем схему подробнее» 39
3. «Отдел выполняет процесс» 40
4. «Статус документа и есть состояние» 40
5. «Всё должно быть в 1С» 40
6. «СМК опишем отдельным процессом» 40
7. «Бухгалтерия потом отразит» 40
8. «Доработка уже есть — надо перенести» 40
9. «Интервью всё объяснит» 40
10. «Схема согласована — проект готов» 40
11. «НСИ настроим перед запуском» 40
Приложение З. Краткий словарь 40
Приложение И. Первый рабочий цикл на одном процессе 41
Шаг 1. Выбрать проблемную конструкцию 42
Шаг 2. Собрать исходные проекции 42
Шаг 3. Выписать существительные и действия раздельно 42
Шаг 4. Проверить кандидаты в бизнес-предметы 42
Шаг 5. Выбрать один предмет-драйвер 42
Шаг 6. Собрать минимальный таксономический паспорт 42
Шаг 7. Провести короткое специализированное интервью 42
Шаг 8. Построить границу процесса и окружение 42
Шаг 9. Собрать минимальную NPA-карту и прикладную проекцию 43
Шаг 10. Провести проверку результата 43
Приложение К. Минимальная карта адаптационного решения 43
Пример фрагмента по регистрации потребности в ТОиР 44
Источники и дальнейшее чтение 44
Фрагмент книги
1. Почему автоматизацию нельзя начинать с диаграммы
На старте проекта кажется естественным спросить сотрудников, как они работают, собрать документы, нарисовать BPMN-схему и затем сопоставить её с функциями 1С:ERP. В этом порядке нет ничего нелепого. Он привычен, понятен заказчику и создаёт видимый результат уже после первых встреч. Проблема обнаруживается позже, когда одна и та же схема начинает одновременно означать фактическую работу, регламент, требования к программе, распределение ответственности и будущую инструкцию пользователя.
Обычно на диаграмме появляются действия подразделений: «создать заявку», «согласовать», «проверить остаток», «сформировать заказ», «выполнить работу», «отразить затраты», «закрыть». Между действиями расставляются стрелки и условия. Формально схема может быть построена без ошибок. Но она не отвечает на главный инженерный вопрос: какая управляемая сущность изменяется в каждом фрагменте и почему эти изменения принадлежат одному либо разным процессам?
Эта неопределённость особенно заметна в проектах 1С. Документ программы легко становится центром модели, потому что он видим, имеет форму, реквизиты, статусы и движения. Пользователь произносит «заявка на ремонт», «заказ клиента», «производственный заказ» или «заявка на оплату», а команда незаметно принимает название документа за название предмета управления. После этого жизненный цикл документа начинает подменять жизненные циклы нескольких разных сущностей.
Например, статус «Согласована» сам по себе ничего не объясняет. Согласована потребность, выбранный способ воздействия, стоимость, срок, задание исполнителю или право вернуть оборудование в использование? Статус «Выполнена» также двусмысленен: выполнена работа, получен технический результат, подтверждено качество либо закрыто обязательство подрядчика? Пока эти различия не сделаны, программный статус создаёт иллюзию определённости.Здесь полезна метафора прибора и его тени. Прибор имеет объёмную конструкцию, узлы, функции, режимы, ограничения и связи с окружающей системой. На стене он оставляет плоскую тень. По тени можно узнать общий силуэт, но нельзя написать точную инструкцию по обслуживанию прибора. Точно так же документ, диаграмма или экран программы является проекцией деятельности, но не самой деятельностью.
Из этого не следует, что BPMN, регламенты или документы 1С бесполезны. Они необходимы. Ошибка состоит в том, что проекция создаётся раньше предметной модели и затем объявляется источником истины. Правильная последовательность обратная: сначала различается предметный мир предприятия, затем из него выводятся процессы, процедуры, схемы, регламенты, требования и прикладные объекты.
Практический признак ранней ошибки прост. Если участники могут долго спорить, где начинается процесс, где он заканчивается и что считается его результатом, а спор решается расширением диаграммы, вероятнее всего, в одной схеме склеены несколько предметов-драйверов. Каждый новый блок делает ватман больше, но не возвращает модели различимость.
Минимальная самопроверка исходной схемы
Возьмите одну действующую процессную схему и попробуйте для каждого крупного фрагмента письменно ответить на пять вопросов:
1. Что именно существует до начала фрагмента?2. Какое состояние этой сущности изменяется?
3. Каким событием подтверждён переход?
4. Где зафиксирован результат и кто вправе его подтвердить?
5. Кому и в каком состоянии сущность передаётся дальше?
Если ответы требуют постоянно менять название сущности — сначала речь идёт о потребности, затем о решении, потом о задании и наконец о результате, — перед вами не один процесс. Это связка процессов, объединённая общей темой или одним программным документом.
2. Как устроена правильная карта проекта
Поэтому у проекта есть несколько уровней, которые нельзя смешивать. Объект автоматизации отвечает на вопрос, какое предприятие или организационная система рассматривается. Подобъекты показывают, где и кем деятельность выполняется. Предметные области разделяют деятельность по управляемому содержанию: производство, ТОиР, транспортная логистика, запасы, закупки, качество, казначейство, учёт и другие области. Бизнес-предметы показывают, чем предприятие управляет внутри и на границах областей. Процессы описывают целенаправленное изменение предметов-драйверов. Процедуры раскрывают работу акторов. Учётный слой устанавливает экономические события. Адаптационный слой связывает требования с параметрами, НСИ, аналитиками, реквизитами, статусами, доступом и отчётами. Операции и прикладные действия доводят процедуру до конкретного сценария 1С:ERP или иной системы.
Это не бюрократическая лестница. Каждый уровень устраняет свой класс неопределённости. Если не установлены подобъекты, невозможно понять, одинакова ли работа на площадках. Если не определена предметная область, процесс начинает поглощать соседние контуры. Если не выделен бизнес-предмет, процесс превращается в последовательность действий. Если не раскрыта процедура, нельзя назначить ответственность. Если не спроектирована адаптационная архитектура, аналитики и обязательные значения не доходят до документов и отчётов. Если отсутствует прикладная проекция, модель не доходит до автоматизации.
Маршрут на рисунке следует читать слева направо и сверху вниз. Он начинается не с интервью «расскажите, как вы работаете», а с предварительного исследования предприятия. Затем проводится первичная инвентаризация: уточняются структура, площадки, предметные области, системы, источники и респонденты. Только после определения охвата формируются специализированные вопросники. Их ответы обновляют предметную модель, из предметной модели выводятся процессы, затем подключаются процедуры и учётный ракурс. После этого NPA-слой определяет параметры, НСИ, аналитики, реквизиты, статусы и доступ, и лишь затем собирается прикладной сценарий и тест.
В реальном проекте шаги могут частично перекрываться. Новый документ выявит дополнительную площадку, интервью обнаружит скрытую систему, предметный анализ потребует уточнить исходный охват. Однако возврат не означает произвольного движения. Каждое изменение должно быть зафиксировано как уточнение модели или открытый GAP, а не растворено в очередной редакции текста.
Что является GAP
GAP — это не только отсутствие функции в программе. Это любая существенная неизвестность, противоречие или неполнота, которую нельзя честно закрыть имеющимися доказательствами. Неясный владелец состояния, противоречащие ответы двух подразделений, неизвестный источник статуса, неполный жизненный цикл предмета, отсутствие полномочия на принятие решения, несовпадение регламента и фактической работы — всё это GAP модели.
Правильная модель не скрывает GAP под словами «уточняется на этапе внедрения». Она показывает, какой элемент неизвестен, почему это важно, кто может дать ответ, какой источник требуется и какое решение будет зависеть от закрытия разрыва. Такая дисциплина защищает проект от тихого придумывания требований.Об авторе
Кирилл Ледовский — бизнес-архитектор, кандидат наук в области информационных технологий, исследователь и автор профессиональных и гуманитарных книг. Более 30 лет он занимается устройством сложных систем — от промышленной автоматизации и ERP до механизмов человеческого поведения, культуры и общества.
В профессиональной серии «Электронная фабрика» Ледовский развивает предметно-ориентированное мышление и системный подход к описанию предприятий, процессов и цифровых моделей. В антропологических работах — прежде всего в серии «Антропология современной личности» — тот же исследовательский метод переносится на человека и общество. Здесь используются антропологический и таксономический подходы: явление разбирается на составляющие, сопоставляется с историческими и социальными формами, а затем собирается в целостную модель.
Его интересуют не столько отдельные события, сколько механизмы, которые стоят за ними: почему общество считает одни формы поведения нормальными, а другие — недопустимыми; как меняются представления о личности, власти, насилии, смерти, свободе и ответственности; каким образом исторические институты продолжают существовать внутри современного человека.
Книги «Как быть?», «Антропология смертной казни» и другие работы этого цикла построены вокруг вопросов, на которые редко существует простой ответ. Это попытка посмотреть на человека одновременно глазами историка, антрополога и системного архитектора — увидеть не только что происходит, но и почему человеческие системы устроены именно так.