- -
- 100%
- +
Именно поэтому Устав в этой конструкции неожиданно оказывается связан не только с началом проекта, но и с тем самым вопросом, который был поставлен во введении: «ERP внедрили. Что дальше?»
Если проект изначально строится как связанная технология получения, проверки и изменения результатов, после его завершения остаётся не только работающая система. Остаётся возможность восстановить происхождение решения, увидеть его профессиональное основание, определить зависимые результаты и понять, что именно понадобится перепроверить при следующем изменении.
Устав тем самым начинает задавать не только способ завершить текущий проект, но и качество будущей изменяемости предприятия.
Есть здесь и ещё один результат, который я долго недооценивал. Хорошо построенная технология меняет не только систему и процессы; она постепенно меняет самих специалистов заказчика. Человек, который раньше просто хорошо знал собственный участок, в ходе проекта начинает различать бизнес-предмет, состояние, событие, основание, критерий, доказательство, зависимость, точку передачи и границу собственного полномочия.
Это особенно важно после завершения внедрения. Если профессиональная логика проекта осталась только у консультантов, предприятие вместе с ними теряет часть способности понимать собственную систему. Если же специалисты заказчика были встроены в технологический маршрут и действительно участвовали в создании, проверке и принятии результатов, после проекта внутри предприятия остаётся не только ERP, но и более зрелый способ работать с её дальнейшими изменениями.
И вот здесь для меня вопрос «что остаётся после проекта?» перестал сводиться к системе, документации и обученным пользователям. Остаётся — или не остаётся — способность предприятия самостоятельно сохранять причинность собственных решений.
Отсюда становится понятна и последняя для этого раздела мысль. Профессиональный смысл не должен после проекта снова распасться между Microsoft Word, Microsoft Excel, схемами, настройками, программным кодом, трекером задач и памятью нескольких специалистов. Все эти инструменты полезны и реально используются в работе, но каждый из них хранит только свою проекцию результата.
Следовательно, где-то глубже должно существовать структурированное цифровое ядро, в котором сохраняются сами сущности, их состояния, связи, основания, версии, зависимости и доказательства. Документ, таблица, схема, пользовательская инструкция или сценарий проверки тогда становятся уже разными представлениями одного и того же принятого содержания.
ERP при таком подходе не теряет своего значения. Она по-прежнему остаётся одной из важнейших систем предприятия, но постепенно перестаёт быть единственным местом, из которого пытаются восстановить всю профессиональную модель бизнеса.
И вот после этого возникает следующий вопрос.
Если не начинать с объектов ERP и не заставлять информационную систему самой объяснять нам, чем живёт предприятие, то с чего вообще начинать восстановление его модели?
С этого места технология переходит к обследованию, вопросникам Q0—Q1—Q2 и предметной инженерии.
II. Сначала нужно понять, чем именно управляет предприятие
В конце предыдущего раздела мы пришли к довольно неудобному вопросу. Если не пытаться восстанавливать предприятие непосредственно из структуры уже работающей ERP, то откуда вообще брать модель? Система перед глазами есть, документы есть, отчёты есть, пользователи прекрасно знают свои экраны, и самый естественный ход аналитика — открыть всё это хозяйство и начать разбираться.
Именно так я сам много раз и делал.
Берёшь подразделение, разговариваешь с руководителем, потом с ключевыми пользователями, смотришь документы, отчёты, настройки, постепенно рисуешь процессы. Через некоторое время появляется вполне убедительная схема действующего предприятия. Проблема обнаруживается позже, когда выясняется, что значительная часть этой схемы на самом деле описывает не деятельность предприятия, а тот способ, которым деятельность сегодня отражена в информационной системе.
Это не одно и то же.
На старых проектах я много раз попадал в эту ловушку. Кажется, что ты обследуешь предприятие, а на самом деле всё глубже обследуешь его ERP. Причём чем лучше знаешь систему, тем легче туда провалиться.
Отсюда и появился принцип, который сегодня кажется мне почти очевидным, хотя пришёл я к нему далеко не сразу.
Структура ERP может быть важнейшим источником обследования, но она не имеет права заранее определять онтологию предприятия. Сначала нужно восстановить профессиональную реальность, а уже потом выяснять, каким образом эта реальность представлена в системе.
Именно поэтому глубокое обследование не начинается сразу с бесконечной серии интервью. До разговора с дорогим специалистом предприятие и проектная команда должны выполнить свою домашнюю работу.
Первый уровень я обозначаю как Q0. Буква Q здесь — просто сокращение от английского question, «вопрос». Q0 — это не вопросник, который посылают пользователю, а предварительное исследование, в котором проект сам собирает доступные источники и строит гипотезу будущего обследования. Мы пытаемся понять структуру предприятия, предполагаемые направления деятельности, предметные области, действующие системы, существующие носители информации и круг специалистов, с которыми вообще имеет смысл разговаривать.
На этом уровне ничего ещё не объявляется истиной. Смысл Q0 как раз в обратном: заранее собрать пространство гипотез, чтобы не расходовать время специалистов заказчика на вопросы, ответы на которые проект мог получить самостоятельно.
Следующий уровень — Q1. Теперь подготовленная карта предъявляется людям, которые действительно способны видеть предприятие шире собственного рабочего места. Здесь уточняется периметр: какие предметные области реально применимы, какие предполагаемые участки деятельности отсутствуют, где проходит организационная граница, какие системы и внешние источники действительно участвуют в работе, кого ещё необходимо подключить к глубокому обследованию.
Q1 поэтому не является просто «более подробным Q0». Его продукт другой. После Q0 у нас есть исследовательская гипотеза, после Q1 — подтверждённый периметр дальнейшего исследования.
И лишь после этого имеет смысл запускать Q2 — предметное и процессное профессиональное обследование уже внутри подтверждённых областей.
Здесь меняется сама точность вопроса. Специалиста больше не просят рассказать, «как у вас устроены закупки» или «чем занимается ваше подразделение». Вопросы начинают строиться вокруг конкретной профессиональной реальности: каким предметом вы здесь управляете, как отличаете один экземпляр этого предмета от другого, в каких состояниях он бывает, что переводит его из состояния в состояние, кто имеет право совершить этот переход, чем он подтверждается, что передаётся следующему участнику и где сегодня фиксируется соответствующая информация.
В результате Q0 → Q1 → Q2 — это не накопление всё большего количества интервью. Это последовательное сужение неопределённости. Сначала пространство возможно очень широкое, затем подтверждается применимый периметр, а внутри него уже восстанавливается фактическая профессиональная модель.
При этом ответ человека не становится нормой предприятия только потому, что этот человек опытный и уверенно говорит. Из обследования отдельно выделяются подтверждённые факты, гипотезы, противоречия, уже принятые решения и открытые вопросы. Если два сильных специалиста описывают один и тот же переход по-разному, нормальная реакция аналитика — не выбрать наиболее убедительного собеседника, а сохранить само противоречие как результат обследования, который требует отдельного разрешения.
Это тоже пришло не сразу. Очень хочется закончить интервью с красивой непротиворечивой картиной. Но иногда честно зафиксированное противоречие значительно ценнее, чем аккуратная схема, в которую аналитик незаметно добавил собственное решение.
Обследование не обязано немедленно производить правильный ответ. Его первая обязанность — отделить подтверждённое знание от гипотезы и не спрятать неопределённость внутри красивой модели.
Внутри Q2 полезно различать два типа вопросов, хотя в реальном интервью они, конечно, пересекаются. Один тип восстанавливает сам бизнес-предмет: его границы, признаки идентичности, характеристики, источники данных, носители контекста и правила качества информации. Второй тип восстанавливает его жизнь в деятельности: состояния, события, роли, процедуры, операции, передачи, обратные связи и существующую автоматизацию.
Это разделение оказалось важным потому, что предмет и процесс — тоже не одно и то же. Предмет существует и сохраняет идентичность, а процесс объясняет, какое существенное изменение этого предмета предприятие пытается получить.
До этого, однако, нужно определить пространство, внутри которого вообще ищутся предметы. Так появляется предметная область.
Под предметной областью здесь понимается не подразделение и не функциональная подсистема ERP, а ограниченный профессиональный мир со своими управляемыми сущностями, состояниями, событиями, правилами и связями. Такая область может организационно пересекать несколько подразделений и технически использовать несколько систем, потому что её граница определяется не оргструктурой и не программой, а содержанием деятельности.
В универсальном доноре, который используется технологией, на текущей версии выделены 23 предметных кластера и 69 предметных областей. Это не означает, что каждое предприятие обязано немедленно получить все 69. Универсальная библиотека вообще не является моделью конкретного предприятия. Она отвечает на вопрос: что уже известно технологии как возможное профессиональное содержание?
Проектная модель отвечает на совершенно другой вопрос: что из этого действительно существует, применимо и подтверждено здесь?
Та же логика относится и к предметной библиотеке. Для версии, описываемой в монографии, приводятся 836 канонических бизнес-предметов, 844 доменные проекции, 637 междоменных интерфейсов и 5 044 записи влияния. Эти цифры я привожу так, как они зафиксированы в материалах; важна здесь не сама величина, а принцип. Универсальная библиотека уже достаточно велика, чтобы работать как профессиональный донор, но конкретный проект не копирует её содержимое целиком. Он формирует собственную проектную библиотеку, в которой остаются только применимые предметы, их фактические проекции, связи и проектные уточнения.
Когда количество канонических предметов перевалило далеко за несколько сотен, для меня окончательно закончилась история про «давайте просто составим хороший словарь терминов». Это уже не словарь. Это материал, из которого можно собирать модель конкретного предприятия, не начиная каждый раз с чистого листа.
И вот здесь появляется ключевое понятие раздела — бизнес-предмет.
Для аналитика прикладной системы очень естественно мыслить документами. Услышал «закупка» — вспоминаешь заявку, заказ поставщику, поступление. Услышал «продажи» — заказ клиента и реализацию. Услышал «ремонт» — заказ на ремонт. В системе это действительно основные точки работы пользователя, поэтому постепенно возникает почти автоматическая подмена: если есть документ, значит, перед нами и есть тот самый бизнес-объект.
Но профессиональная реальность обычно устроена сложнее.
Закупочная потребность не равна заявке. Заявка не равна закупочной процедуре. Закупочная процедура не равна решению о выборе поставщика. Решение не равно договорному обязательству. Обязательство не равно заказу поставщику, а заказ не равен самой поставке.
Система вполне может объединять несколько этих смыслов в одном техническом объекте либо, наоборот, разносить один профессиональный предмет по нескольким объектам. Но техническая форма не должна определять, сколько самостоятельных предметов существует в деятельности.
Бизнес-предмет в этой конструкции — самостоятельная управляемая сущность, которая обладает собственной идентичностью, смысловой границей и жизненным циклом.
Идентичность отвечает на вопрос, по каким признакам мы понимаем, что перед нами всё ещё тот же самый предмет, несмотря на изменение его характеристик и состояния. Смысловая граница определяет, что относится к этому предмету, а что уже является другим предметом или только его характеристикой. Жизненный цикл показывает, какие значимые состояния предмет может проходить и какие события способны эти состояния изменить.
Вот здесь я бы сегодня остановил аналитика перед открытым экраном ERP и сначала задал ему один вопрос: что именно существует в предприятии независимо от того, каким документом или набором регистров это сейчас представлено? Если на этот вопрос нет ответа, прикладное сопоставление ещё рано начинать.
Бизнес-предмет существует в профессиональной реальности предприятия. ERP-объект — только одна из возможных технических проекций этого предмета.
Чтобы библиотека таких предметов не превратилась со временем в ещё один бесконтрольный словарь, появляется таксон. Здесь я использую это слово в довольно инженерном смысле: таксон — нормализованное описание класса бизнес-предметов, позволяющее одинаково понимать его в разных проектах и затем корректно проектировать конкретные экземпляры и проекции.
У таксона есть паспорт. В нём фиксируются нормативное имя и определение, критерии включения и исключения, признаки идентичности, значимые характеристики, возможные состояния и типы событий, типовые связи, источники, носители контекста и доказательства. Отдельно важно помнить, что паспорт описывает возможную жизнь предмета, но не назначает ему заранее процессную роль.
Это принципиально. Предмет сам по себе не является «входом», «выходом», «доказательством» или «драйвером». Такие роли возникают только тогда, когда предмет включён в конкретный процесс.
То же относится и к месту, где сегодня хранится информация. Я использую термин «носитель контекста» для того места, в котором на текущий момент зафиксирована информация о предмете: это может быть ERP, электронная таблица, текстовый документ, специализированная производственная система, бумажный документ, программный интерфейс обмена или другой носитель. Носитель важен для восстановления фактического состояния, но сам по себе он тоже не становится предметом.
Здесь особенно легко смешать разные сущности. Состояние бизнес-предмета — не то же самое, что событие; событие — не то же самое, что подтверждающий факт; факт — не документ; документ — не носитель; носитель — не поле; поле — не характеристика предмета. Пока эти различия не проведены, модель выглядит проще, но дальше практически неизбежно начинает ломаться трассировка.
Предмет без состояний вообще трудно использовать для управления. Поэтому следующим шагом восстанавливается его жизненный цикл. Состояние описывает профессионально значимое положение предмета в некоторый момент времени, а событие либо переводит его в другое состояние, либо подтверждает существенный факт, связанный с этим состоянием.
В простейшем виде это можно записать как: исходное состояние → событие → новое состояние. Но для проекта важна не сама стрелка, а всё, что стоит вокруг неё: кто имел право вызвать событие, на каком основании, какие условия должны быть выполнены, чем подтверждается переход и какие действия становятся допустимы после него.
Эта точка очень важна для уже внедрённой ERP. В системе обычно имеется много технических статусов, признаков проведения, состояний обмена и служебных флагов. Они полезны, но не всякий системный статус является профессиональным состоянием предмета. И наоборот, профессионально значимое состояние иногда вообще не представлено одним отдельным полем и вычисляется из совокупности данных.
Поэтому задача обследования — не переписать значения поля «Статус», а восстановить профессиональную машину состояний: что действительно изменяется в деятельности предприятия и каким наблюдаемым событием это изменение подтверждается.
И только после этого появляется процесс.
Это один из тех моментов, где у меня за годы работы действительно поменялся порядок мышления. Раньше естественно было начинать с вопроса «какие у вас бизнес-процессы?». Сегодня я сначала спрашиваю: какими предметами предприятие управляет и какие существенные изменения их состояния оно пытается получить?
Процесс в такой конструкции выводится из предмета. Для каждого самостоятельного бизнес-процесса должен существовать один предмет-драйвер — предмет, существенное изменение которого удерживает смысловую границу процесса.
Это сразу решает довольно старую проблему гигантских сквозных процессов. Например, под одним названием «Закупка» легко объединить возникновение потребности, подготовку заявки, проведение закупочной процедуры, выбор поставщика, возникновение обязательства, заказ, поставку и расчёты. На картинке это выглядит удобно, но внутри такой схемы одновременно живут несколько разных предметов с разными жизненными циклами.
Если драйвер меняется, значит, очень возможно, что закончился один процесс и начинается другой.
Вокруг предмета-драйвера находятся другие предметы, которые создают предметное окружение процесса. Они могут обеспечивать работу данными и ресурсами, служить доказательствами, задавать ограничения, использоваться в расчётах или выполнять контрольную функцию. При этом обеспечивающий или доказательный предмет не становится автоматически самостоятельным процессом и не образует собственную горизонтальную линию передачи только потому, что участвует в деятельности.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.