ERP-Лабиринты. Где выход?

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

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

Задача книги не в том, чтобы доказать, что BPMN, 1С: ERP или документы бесполезны. Они необходимы. Но они начинают работать только тогда, когда становятся представлениями уже различённого предметного мира.

Как выйти из этого лабиринта

Один пример не позволяет самостоятельно восстановить предметно-процессную архитектуру предприятия. Это было бы таким же упрощением, как обещание собрать весь ТОиР из одной заявки.

Практический выход начинается с предметно-ориентированного проектирования. До детальной автоматизации должен существовать минимальный состав модели: предметные области и их границы, бизнес-предметы, таксономические паспорта, состояния и события, предметы-драйверы, обеспечивающие и доказательные предметы, границы бизнес-процессов, роли, межпроцессные передачи и связь предметов с объектами 1С: ERP.

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

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

В таком проекте необходимо не перерисовывать существующий ватман, а определить предметный охват предприятия, собрать таксономические паспорта, восстановить связки процессов, проверить междоменные передачи и сформировать опорное предметно-процессное ядро проекта. Только на нём имеет смысл строить требования, модели 1С: ERP, расширения, инструкции и контроль результата.

Когда проект оказался в ERP-лабиринте, выход начинается не с новой стрелки. Он начинается с восстановления предметного мира, тенью которого были все прежние схемы.

На ремонтах хорошо видно, как привычная заявка постепенно начинает изображать собой целую предметную область. Но эта ошибка не зависит ни от простоты процесса, ни от длительности его цикла: она повторяется и там, где объектом управления становится многомесячная инженерная разработка. Поэтому следующий шаг — проверить ту же логику на НИОКР, где за одной темой разработки скрываются требования, версии, исследования, проектные решения и результаты испытаний.

Глава 2. ERP-лабиринты: автоматизация НИОКР — тема разработки ещё не процесс

Почему карточка темы, ТЗ и календарный план ещё не образуют архитектуру разработки

Автоматизация НИОКР часто начинается с очень понятной конструкции. Есть тема разработки, у неё есть руководитель, этапы, сроки и бюджет; дальше появляются техническое задание, план работ, конструкторская документация, испытания и итоговый отчёт. Остаётся нарисовать последовательность, назначить ответственных и подобрать объекты 1С: ERP, PLM или СЭД, которые будут сопровождать каждую стадию.

На первый взгляд всё выглядит почти очевидно. В 1С: ERP действительно можно вести темы и этапы исследований и разработок, задавать их иерархию, плановые даты, различать исследования и разработки, накапливать по ним затраты и определять дальнейший порядок их признания. Для учёта это совершенно нормальная прикладная конструкция.

Проблема появляется в тот момент, когда карточку темы начинают принимать за сам предметный мир НИОКР.

Первая попытка: провести одну тему от идеи до результата

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

Для совещания такая схема удобна. Руководитель понимает общую последовательность, исследователь видит свой участок, конструктор — свой, финансовая служба получает этапы, к которым можно относить затраты. Если добавить дорожки подразделений, решения «да/нет» и несколько возвратов, получится вполне профессиональная BPMN-модель.

И именно поэтому её ограничение долго не замечают.

Слово «тема» начинает незаметно менять смысл. Сначала это управляемая единица НИОКР. Потом под ней фактически понимают совокупность требований. Затем — календарный план. Позже — программу исследований, набор экспериментальных данных, проектное решение, комплект КД, определённую версию изделия, результаты испытаний и, наконец, результат, который должен быть передан следующему владельцу.

На схеме стрелка остаётся непрерывной. Но предмет уже несколько раз сменился.

BPMN снова ни в чём не виновата

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

Между блоками «Сформировать требования» и «Разработать решение» можно провести одну красивую стрелку. Но внутри этой стрелки существуют отдельные требования, их согласованный комплект, базовая линия требований, решения об изменениях, проектное решение и последующие версии разработки. У каждого из этих предметов свои владельцы содержания, состояния, основания изменения и доказательства.

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

Непрерывность стрелки ещё не означает непрерывность предмета.

Это особенно хорошо видно, когда на схеме появляется свёрнутый подпроцесс. Предмет уходит внутрь блока «Провести исследования», а с другой стороны появляется «Результат исследования». Визуально кажется, что это один и тот же объект, просто прошедший некоторое преобразование. Но между входом и выходом могли возникнуть гипотеза, программа, экспериментальная серия, набор данных, интерпретация и несколько промежуточных решений. Если они не различены как предметы, значительная часть управляемой реальности просто исчезает внутри прямоугольника.

Вторая попытка: добавить в одну схему весь НИОКР

После первых вопросов аналитик обычно начинает расширять модель.

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

Затем приходит производственный контур. Он спрашивает, когда появляется опытный образец и кто отвечает за его изготовление. Технологи хотят получить КД и вернуть оценку технологичности. Финансовая служба требует связать тему и этапы с накоплением расходов. Документообороту нужны протоколы, отчёты и зарегистрированные комплекты документов. Если часть работ выполняется внешним институтом или конструкторским бюро, в модель добавляются договор, внешний исполнитель, получаемый результат и его приёмка.

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

Схема стала значительно полнее. Но понимать её стало труднее.

Предметы возникают в разных дорожках и там же исчезают. Один и тот же объект называется по-разному у разных участников. Некоторые связи уходят в другие схемы, некоторые — в подпроцессы, а часть смысла просто помещается в поля документов. В итоге только автор модели ещё помнит, почему эта стрелка идёт именно сюда и какой объект должен вернуться из соседнего контура.

Так появляются знаменитые «процессы на ватмане», которыми иногда даже гордятся: настолько всё серьёзно, что одного листа уже недостаточно.

Размер схемы в данном случае характеризует не глубину модели. Он показывает, насколько много различных предметных миров удалось спроецировать на одну плоскость.

Объёмная разработка и её плоская тень

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

Тень реальна. Она правильно показывает некоторую проекцию объекта.

Но по тени невозможно восстановить устройство изделия.

Карточка темы НИОКР — такая же проекция. Она прекрасно подходит для идентификации темы, фиксации сроков, иерархии этапов, ответственных и учётной аналитики. Но за ней находится значительно более объёмная конструкция: проблема и идея, концепция, целевой результат, отдельные требования, базовая линия требований, планы и программы, гипотезы, данные, проектные решения, модели, КД, версии, изменения, замечания, результаты проверки, оценки зрелости и пакеты передачи.

Если вся эта архитектура сворачивается в одну карточку, программа не становится проще. Она лишь перестаёт показывать различия между предметами.

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

Предмет-драйвер не существует в одиночестве

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

У конкретного бизнес-процесса действительно должен быть предмет-драйвер — тот предмет, изменение состояния которого удерживает границу процесса. Но вокруг драйвера существует предметное окружение. Одни предметы обеспечивают его движение, другие являются доказательствами, третьи задают ограничения, четвёртые передаются из соседних процессов.

И один и тот же предмет в разных процессах может играть разную роль.

Тема НИОКР является предметом-драйвером при её открытии. Но когда начинается работа с требованиями, сама тема уже становится контекстом: драйвером является базовая линия требований.

Базовая линия требований является результатом самостоятельного процесса. Для проектного решения она становится обязательным управляющим входом: решение должно создаваться не «по теме вообще», а по конкретной принятой версии требований.

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

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

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

Поэтому полная картина НИОКР строится не вокруг одного «проекта», «темы» или «ТЗ», а вокруг сети предметов, которые меняют состояние и передаются между самостоятельными процессами.

Зачем предмету нужен таксон

В НИОКР особенно легко обмануться одинаковыми словами.

Техническим заданием могут называть документ, комплект требований или саму задачу исполнителю. «Проектом» называют тему НИОКР, проектное решение, комплект проектной документации или организационный проект. «Испытаниями» называют программу испытаний, методику, фактический эксперимент, набор данных и итоговый протокол. «Результатом» могут одновременно считать научный вывод, КД, опытный образец или закрытую тему.

Поэтому названия недостаточно.

Чтобы один предмет можно было отличить от другого, ему нужен таксон — нормализованное описание его идентичности. Таксон фиксирует, что именно считается предметом, где проходит его смысловая граница, кто владеет содержанием, какие минимальные характеристики нужны, какие состояния предмет проходит, какими событиями изменяется, чем переход подтверждается, какими носителями представлен и с какими предметами связан.

Рассмотрим тему НИОКР.

Тема — не строка справочника и не папка документов. Это идентифицированная единица управления НИОКР, которая связывает проблему, цель, границы, этапы, требования, исполнителей, сроки и ожидаемый результат. Карточка темы в ERP, PLM или СЭД является прикладным представлением этого предмета.

Теперь возьмём базовую линию требований. Это тоже не просто статус документа «ТЗ утверждено». Базовая линия — утверждённая версия согласованной совокупности требований, используемая как основание для разработки, проверки и последующего контроля изменений.

Или проектное решение. Оно не равно комплекту КД. Сначала предприятие выбирает и фиксирует инженерный принцип решения, затем подтверждает его моделями и расчётами, а уже после этого выпускает документированный комплект конструкторских материалов.

Пока эти различия не закреплены, проект не способен точно ответить на простые вопросы: что именно изменилось, какая версия действует, что было проверено, к чему относится замечание, на основании чего выпущена новая КД и какой результат принят.

НИОКР не является островом внутри предприятия

Полный цикл НИОКР начинается не с того момента, когда сотрудник нажал «Создать тему», и заканчивается не закрытием карточки.

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

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

Рядом находится технологическая подготовка производства. НИОКР передаёт проектное решение и КД, технологическая служба определяет технологию изготовления, маршруты, нормы и ограничения, после чего возвращает оценку технологичности. Нельзя просто добавить на схему НИОКР блок «Разработать технологию» и считать вопрос закрытым: это уже жизненный цикл другой предметной области.

Серийное производство получает принятый и подготовленный результат, а не саму тему НИОКР.

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

Есть и финансовая проекция. В 1С: ERP темы и этапы исследований и разработок используются для детализации затрат; накопленные расходы по исследованиям и разработкам могут получать различный дальнейший учётный статус. Но это означает только то, что у предметного мира НИОКР есть финансовый след. Учёт расходов не является самим управлением НИОКР.

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

Пятнадцать групп и восемнадцать процессов вместо одной темы

Если разложить полный цикл НИОКР по предметам, вместо одного большого процесса «Разработка нового изделия» появляется значительно более точная архитектура.

В ней выделено 15 групп и 18 бизнес-процессов.

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

Далее формируется и управляется базовая линия требований. Отдельный процесс отвечает за планирование НИОКР, программы и методики исследований, испытаний и измерений. Ещё один — за патентные и информационные исследования.

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

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

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

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

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

Кроме основной цепочки существуют специализированные процессы: разработка и интеграция программно-аппаратной составляющей, метрологическое обеспечение, а также организация и приёмка кооперационной НИОКР с внешним исполнителем.

За этими восемнадцатью процессами находятся 105 процедур и 420 операций.

Это не призыв нарисовать диаграмму из 420 прямоугольников. Наоборот.

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

Так появляется масштаб, но не возникает ватманная паутина.

Один процесс в правильном окружении: открыть тему НИОКР

Теперь можно увеличить только один фрагмент общей карты.

Допустим, предприятие решило открыть тему НИОКР.

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

Предметом-драйвером рассматриваемого процесса становится тема НИОКР.

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

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

После этого оцениваются ресурсы и ограничения. Это не означает, что процесс открытия темы внезапно превращается в бюджетирование или управление персоналом. Финансовые и ресурсные предметы выступают обеспечивающими входами: нужно доказать, что тема в заданных границах вообще может быть принята в управление.

Дальше формируются материалы для научно-технического совета.

Последний участок — принятие и регистрация решения.

Тема может быть открыта. Может быть возвращена на уточнение концепции. В открытии может быть отказано, если необходимость отдельной НИОКР не доказана или если целевой результат неотделим от обычного текущего проектного задания.

Нормальное завершение процесса наступает не тогда, когда проведены исследования, выпущена КД или изготовлен опытный образец.

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

Дальше начинается другой процесс — управление жизненным циклом темы и этапов. Затем другие процессы будут работать с требованиями, планами, исследованиями, проектными решениями и результатами.

Граница оказалась короткой.

Но именно поэтому она стала управляемой.

Почему справочник 1С: ERP ещё не является системой управления НИОКР

Здесь обычно возникает понятный вопрос: если в 1С: ERP уже есть «Темы, этапы исследований и разработок», зачем вообще строить дополнительную предметную модель?

Потому что прикладной объект и бизнес-предмет отвечают на разные вопросы.

Прикладной объект отвечает: где сохранить информацию, какой реквизит заполнить, к какой теме отнести расходы, как показать этап и какой документ сформировать.

Бизнес-предмет отвечает: чем именно предприятие сейчас управляет.

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

Если проектная команда сама этого различения не сделала, все предметы постепенно начинают складываться в один прикладной объект. Сначала появляются дополнительные реквизиты. Затем статусы. Потом вложенные файлы и комментарии. Затем отдельные регистры, расширения и внешние таблицы.

И через некоторое время система задаёт вопросы, на которые карточка темы принципиально не может ответить.