Для представления статьи читателям, во-первых, скажу, что, перефразируя слова А. Казанцева, я назвал бы эту публикацию так: «Как преодолеть ошибки корпоративных программ цифровой трансформации». Во-вторых, процитирую фрагмент заключения: «Публикация метода, надеюсь, подводит черту под подзатянувшейся дискуссией на isicad о том, что можно жить по принципу “воровать чужие идеи и делать на этом успешную карьеру”. Чтобы ворованная идея для вас стала эдаким “бустером”, нужно украсть всю иерархию ключевых идей с подробным описанием, при этом ключевые факторы влияния должны быть определены верно, а это значит, что хозяйственный механизм должен совпадать как по структуре, так и по фазе, что всё вместе выглядит очень маловероятно... Ну украдёте вы резинку от трусов, а вам надо шапки шить. И что с этим будете делать?… 
».
На мой взгляд, вступительно-диагностирующая часть статьи полезна большинству читателей, а основная часть – с описанием метода, предлагаемого автором, – пожалуй, ориентирована на тех, кто имеет реальный опыт организации и управления в производстве.
***
Все публикации автора на isicad.ru, начиная с 2014 года.
| «Рост объёма и сложности систем является жизненной реалией.
Эту предпосылку нужно принять как неизбежную. Но ошибочное определение системы не является неизбежным: оно – результат неадекватности методов создания систем». |
|
Дэвид А. Марка (SADT) |
1. Предпосылки статьи, или Дурная бесконечность
В последнее время, по служебной необходимости, я вынужден был прочитать довольно большое количество документов на разработку корпоративных информационных систем управления, построенных на использовании инженерных данных, которые гордо озаглавлены аббревиатурами «АСУ» и «BIM». Дело тут, конечно, не в модном BIMе. У машиностроителей трёхмерный САПР в связке с СУБД крутится уже лет 20 – и (важно!) без особого шума, что, несомненно, помогло разработать действительно полезные прикладные инструменты для инженеров. Проблема в том, что мода на BIM совпала с волной, поднятой государством, – «цифровой трансформацией» экономики.Наше любимое государство этим решает свою проблему – снижение дотационного бремени, перевод отсталых секторов на самоокупаемость. И ради этого готово инвестировать в эти самые сектора. Проблема заключается в том, что инвестиции должны упасть на подготовленную почву. «Почва» в данном случае – это корпоративная деловая и техническая культура, которая самым непосредственным образом выражается в фактически используемых методах принятия решений.
Чтобы понять, о чём пойдёт речь дальше, приведу определение важного термина.
Хозяйственный механизм (сокр. ХМ) – симбиоз объективно сложившихся внешних условий (среды) и субъективно построенного производственного (бизнес-)процесса1.
1Если этот симбиоз неполный – возникают явления, которые называют «сбои хозяйственного механизма».
Из определения видно, что положительный результат возникает не от нового информационного объекта (регламента, программы или технологии) самого по себе, но только в результате взаимодействия нового объекта с существующим хозяйственным механизмом. Образно говоря, новый «движок» должен не только иметь выдающиеся ТТХ, но ещё и влезать в капот вашей машины – иначе вы никуда не поедете.
Рассмотренные мной проектные документы, как под копирку, имеют общие ошибки, которые можно разбить на два блока «общих ошибок корпоративных программ цифровой трансформации».
Блок 1: Показатели разработки ИС (АСУ)
- отсутствует текущая система натуральных показателей деятельности ХМ компании (что измеряем, что имеем);
- отсутствуют формулы пересчёта натуральных показателей в денежные (доход) по каждому показателю/группе схожих показателей (как считаем);
- отсутствуют значения планового прироста показателей с обоснованием достижимости этого прироста по каждому показателю в результате внедрения цифрового вундерваффе (где количественный эффект? за счёт чего?);
- декларируемый рост доходности не имеет расчёта (по тем же формулам!) на основании прироста натуральных показателей (цифры «от балды»).
Блок 2: Подмена объективного подхода субъективными ожиданиями
Сначала пишутся стратегические цели компании, перечисляются указы Президента РФ по цифровизации, постановления Правительства в развитие указов, идут массовые ссылки на корпоративные документы и прочая. Потом, когда доходит до детализации в структурных подразделениях, все эти общие документы подменяются «хотелками» с мест (длиииииинным нумерованным списком!) без обоснования достижимости стратегических целей при реализации этих «хотелок». Почему выбраны эти предложения, а не другие, какая между ними связь – непонятно. «Это сейчас модно – и всё» ©. Очевидно, что при таком подходе успех случаен, а вот растрата инвестиций на ложные цели – неминуема.
Что мы видим в итоге? Существующий хозяйственный механизм игнорируется напрочь. Его анализ заменяется подтасовками. Это очень серьёзная, давняя и плохо понимаемая проблема.
Объективный критерий успеха продукта (автомобиля или рыночного САПР) очень прост – это объём продаж. Хорошо продаётся – разработчикам всё простят, плохо продаётся – «кому здесь нужно ваше жалкое блеяние?» ©
А вот для оценки успеха средств производства (например программы АСУ для нужд компании) должна быть разработана система показателей, понятная капиталисту:
Показатели → Цифровая трансформация → Показатели+ (как аналог Д → Т → Д+).
Но поскольку никто не будет вводить новые показатели для какой-то одной программы2 (оценивать их значимость, взаимосвязь, собирать статистику применения и прочая), то базироваться надо на существующих экономических показателях ХМ компании.
2 Формирование системы показателей хозяйственной деятельности компании является отдельной большой темой. По сути, руководство осуществляет управление компанией, сверяясь с текущими значениями системы показателей и сравнивая их с нормативными.
Так врач судит о наличии воспалительного процесса в организме, сверяясь с показателем температуры тела больного. Поэтому показатели, которые ни о чём ему не говорят, врачу не нужны. С другой стороны, наихудший случай, когда все показатели в норме, а пациент умирает. Управление предприятием (или правильнее всё-таки говорить – хозяйственным механизмом) имеет очень много схожего с медициной. О некоторых проблемах выбора показателей можно прочесть здесь: Новогодний винегрет.
Важным моментом здесь является то, что с системой показателей ХМ компании связаны KPI руководства. Улучшение показателей, от которых зависит их премия, всеми понимается очень хорошо.
Соответственно, если меняется система показателей – должны пересматриваться и требования к системам управления… Это что касается ошибок 1-го блока.
По 2-му блоку суть проблемы точно определена Дэвидом Марка (см. цитату в начале статьи). Сегодняшняя система ГОСТ 34 на разработку ИС, на мой взгляд, морально устарела3. Во-первых, она очевидно рассчитана на полный цикл разработки софта, но в случае популярных сегодня интеграционных проектов, по моему мнению, нужна другая схема. Во-вторых, отсутствуют эффективные методики разработки ключевых документов на ранних стадиях, в первую очередь – функциональных требований (ФТ) со стороны заказчика.
3 Злые языки даже поговаривают, что основные положения были скопированы с американского ИТ-стандарта 70-х годов.
По-моему опыту, наибольшие проблемы, влияющие на успех ИТ-проекта, возникают именно здесь. Заказчик не имеет методических инструментов для формулировки этих требований, поэтому документ превращается в список субъективных высказываний о том, «у кого что чешется». После чего ИТ-подрядчик, нежно обнимая заказчика, делает следующий шаг в пропасть: заказчику предлагается провести обследование, выявить проблемы заказчика и самим сформулировать, что надо сделать. Никого не пугает, что сроки обследования, откровенность сотрудников заказчика и компетенции «аналитиков» подрядчика могут быть недостаточными. Апофеозом вполне может стать информационная система, которая никому не нужна.
Разумным действием для руководства компании в решении задачи «как не растранжирить деньги на ИТ» является проведение внутрикорпоративного конкурса на функциональные требования к ИТ-проекту, когда групп разработки ФТ как минимум две4. Тогда по итогам можно премировать победителя и сформировать сводные ФТ, которые наверняка будут лучше тех, что по отдельности.
4 Оценить значимость ИС можно, предварительно прикинув стоимость той информации, которая будет в ней находиться после ввода в эксплуатацию. Например, мне известен проект АСУ, в котором после завершения разработки должна крутиться информация по основным фондам капитального строительства на несколько триллионов рублей. Конкурс на ФТ здесь очевиден.
Но данный организационный приём не снимает проблему снижения субъективности и повышения внутренней связности предложенных требований. «Как научить людей сразу думать правильно?» © Для решения этих задач предлагается использовать «матричный метод», описанный ниже.
2. Описание метода
2.1. «Полезная» цель
На данном этапе достаточно кратко ответить на два вопроса:
Вопрос 1. Что является целью: предмет потребления или средство производства?
Если это предмет потребления, то характеристиками объекта являются потребительские свойства, за которые потребитель готов заплатить. Соответственно, дальнейший анализ потребует знания правил маркетинга, такой специалист должен быть в команде проекта.
Если это средство производства, то характеристиками объекта являются показатели эффективности. Здесь в команде обязательно нужен технолог, который знает производственный процесс.
P.S. Все программы, официально используемые на вашей работе, являются средствами производства.
Вопрос 2. Является ли разрабатываемый объект продуктом?
Здесь имеется в виду: собираетесь ли вы в дальнейшем разрабатываемый объект продавать на рынке? Это сразу определяет: периметр проекта/возможных стейкхолдеров, необходимость в маркетологических исследованиях (даже если это средство производства), внутреннюю архитектуру объекта и т. п.
P.S. Сейчас пошла мода при выбивании бюджета на разработку корпоративной ИС заявлять, что «вот мы сейчас сделаем для себя, а на втором этапе будем продавать её на рынке и окупим все затраты, так дайте ж денег нам скорее!» Если руководство не хочет верить честным задорным лицам, то полезно поинтересоваться: какие меры по обеспечению успеха будущего ИТ-продукта будут заложены уже на первом этапе, насколько профессионально проведен анализ возможных рынков сбыта и условий продаж? В противном случае велик риск, что для рынка корпоративную программу придётся переписать почти полностью.
Ну а коронная фраза «мы занимаемся автоматизацией производства, экономика нас не интересует» должна заставить даже задремавшее руководство насторожиться...
2.2. Определение ключевых факторов влияния
Итак, положительный результат возникает не от нового объекта самого по себе, но только в результате взаимодействия нового объекта с существующим хозяйственным механизмом.Хозяйственный механизм (ХМ) может быть представлен в виде группы независимых переменных, которые оказывают постоянное существенное влияние на это взаимодействие. Эта группа переменных называется Ключевые факторы влияния (КВФ). Другими словами, КВФ отражают важные особенности среды, в которой предстоит «работать» новому объекту.
Наилучший учёт КВФ означает максимальную приспособленность объекта к работе в этих условиях. Таким образом, с КВФ не борются, к ним адаптируются5. Задача анализа КВФ – повысить адаптивность разрабатываемого объекта к существующему ХМ6.
5 Пример: На улице -15°С мороза. Вы же не боретесь с морозом, вы к нему адаптируетесь – надеваете шубу. Шуба – это наилучший способ адаптации из возможных, кто в шубе – тот лучше себя чувствует.
Следовательно, чем выше адаптивность фирмы к КВФ, тем лучше она себя чувствует на рынке (секрет конкурентоспособности).
6 Это принципиально отличается от «западного» подхода, где в качестве ключевых факторов предлагается выбирать свои «хотелки» – ключевые факторы успеха (КФУ), для реализации которых может просто не оказаться возможных решений.
Принцип адаптации не отрицает инноваций в ХМ, поскольку инновация может дать наибольшую адаптивность субъективно построенного производственного процесса к объективно сложившимся условиям внешней среды7 (а может и не дать, тогда эта инновация – бесполезна).
7 См. определение хозяйственного механизма выше.
2.3. Формулировка новой парадигмы
Перечень КВФ дополняется развёрнутым обоснованием выбора каждого фактора. Анализ КВФ формирует новую парадигму – основную идею будущего объекта/продукта.Важной особенностью парадигмы является то, что она позволяет преодолеть ограничения КВФ либо решить связанные с ними проблемы, которые старая парадигма, включённая в существующие процессы ХМ, решить не могла.
На этапах выбора КВФ и формулировки парадигмы важную роль в команде играют участники, обладающие талантом исследователя. На эту тему более развёрнуто здесь: Наблюдение за наблюдающим: о методе isicad-а.
Другой важной особенностью/признаком парадигмы является то, что, сама являясь идеей, она работает как «генератор» новых идей. Эти идеи, согласно рассматриваемому методу, собираются в «матрицу».
2.4. Ключевые идеи и «матричная» модель объекта
Рис. 1. Старт «матричной» модели
Однако КИ должны пройти проверки на адекватность, целостность и непротиворечивость. Для этого строится матрица КИ – см. рис. 1.
Совокупность Кii (элементов на главной диагонали) – это сами идеи, это их описание с указанием на то, с какими факторами влияния они связаны/на какие факторы влияния они воздействуют.
Совокупность Кij (элементов не на главной диагонали) – это описание влияния одних идей на другие, причём влияние КИ1 → КИ2 (элемент К12) и влияние КИ2 → КИ1 (элемент К21) – это разные влияния и они должны быть описаны отдельно.
Проверки:
- Проверка на адекватность: Не должно быть Кii без связи хотя бы с одним фактором.
- Проверка на целостность: Не должно быть фактора, не связанного хотя бы с одним Кii.
- Проверка на непротиворечивость: Ни одно из описаний взаимовлияния Кij не должно быть антагонистичным по отношению к другим (между идеями не должно возникать противоречий). Ни одна идея не должна подавлять другую.
Примечание 1: чем на большее число факторов влияет КИ, тем лучше – значит выбрана более «весомая» идея. Таким образом, в рамках проектной команды возможен «конкурс идей», которые оцениваются на право быть включёнными в список КИ. Правильность подбора КИ зависит от профессионализма команды.
Примечание 2: следует внимательно относиться к недиагональным «нулевым» элементам матрицы («нет связи»). Возможно, связь всё-таки есть, но не была выявлена.
2.5. Построение матричной иерархии
Метод «матрицы объекта» иерархичен, то есть каждая КИ из матрицы i-го уровня является парадигмой для следующего уровня иерархии i+1, где её декомпозиция формирует новую матрицу. Таким образом создаётся своего рода непрерывно действующий «генератор идей».При этом анализ недиагональных элементов матрицы играет важную роль:
- связи между элементами КИ формируются только на своём уровне, «гибельной» для больших проектов путаницы межуровневых связей не возникает;
- выявление взаимовлияний КИ из матрицы i-го уровня нередко приводит к лучшему пониманию задач и более быстрому нахождению КИ уровня i+1.
Проверки КИ на адекватность, целостность, непротиворечивость и инвариантность должны выполняться всегда, для каждой матрицы каждого уровня8.
8 Требование к инвариантности ключевых идей матрицы и проверки взаимовлияния КИ друг на друга (недиагональные элементы матрицы) не противоречат друг другу: когда изначально независимые идеи объединяются в систему (матрицу), то они начинают друг на друга влиять. Пример: в собранном автомобиле вибрация двигателя передаётся на его кузов.
2.6. «Разделяемые» элементы
Со 2-го уровня иерархии начинают появляться КИ, которые являются общими для разных матриц одного уровня, – то есть чтобы обеспечить выполнение конкретной матричной «парадигмы», эта КИ должна присутствовать обязательно. Это так называемые «разделяемые КИ», которые относят к одной из матриц уровня, а в других она упоминается как ссылка на матрицу-смежника.Для назначения ответственности за исполнение матричных КИ назначается «хозяин матрицы», его синонимом является «руководитель проекта» в большом проекте (программе проектов), где таких РП может быть много. Хозяин матрицы несёт ответственность за своевременное выполнение своего «разделяемого КИ» и обеспечение его результатами смежников.
Матричная парадигма считается исполненной, если все матричные КИ выполнены. Контроль исполнения КИ со стороны директора проекта (по всему разрабатываемому объекту) ведётся по чек-листам.
2.7. О статической и динамической проверках матричной модели
Метод «матрицы» очевидно функционально-ориентирован, иерархичен, а значит представляет из себя «статичную» модель разрабатываемого объекта, где роль проверок «статики» играют вышеописанные проверки на адекватность, целостность и т. д.А «динамика» построенной модели объекта, своего рода конструктивные испытания, проверяется через построение «процессной модели» объекта разработки, когда каждой операции процесса должна соответствовать некая функция (КИ) в матрице.
Если такой КИ не находится, то это повод для пересмотра отдельных подструктур матрицы: правильно ли был определён состав КИ?
После успешных динамических испытаний можно переходить к формированию проектных документов «функциональные требования» и «техническое задание».
2.8. Ещё раз о показателях
Важно понимать, что система показателей ХМ и сам ХМ – это не одно и то же. Система показателей ХМ является, по сути, моделью ХМ. В действующем ХМ существуют факторы, оказывающие влияние на целевые значения его показателей. Считается, что система показателей адекватно отображает влияние этих факторов (модель ХМ адекватна реальному ХМ). Проще говоря, «факторы – это то, что действует, а показатели – то, на что смотрят» ©. А вот если состав ключевых факторов влияния начинает меняться... возможно, вам потребуется пересмотр системы показателей. Но это отдельная тема для анализа.В завершение необходимо сказать о связи системы показателей ХМ и «матричной» модели. В перечень КВФ должен явно попасть хотя бы один фактор, стоящий за каким-либо вычисляемым показателем системы показателей ХМ компании. Иначе вы получите «сферического коня в вакууме» – информационная система сама по себе, действующий ХМ – сам по себе. Но означает ли это обязательный провал ИС? Нет, «только ситхи всё возводят в абсолют» ©. При проектировании иерархии «матриц» возможно появление КИ, которые окажут существенное влияние на контролируемые системой показателей факторы ХМ. Но, как вы понимаете, если фактор не указан явно, то появление «удачного» КИ – воля случая.
3. Заключительное слово
Методика построения «матрицы объекта», конечно, не даёт гарантий создания успешного продукта, но она делает процесс его разработки более технологичным, а следовательно, повышает шансы на успех.Анализ самого метода позволяет дать ответ на многие интересные вопросы, например: почему одни проекты получаются, а другие нет? Почему мы видим на рынке такие разные предложения продуктов? Потому что команды разные, люди все уникальные, а значит в голову приходят разные КИ, даже если декомпозируются схожие парадигмы. Где-то эти КИ более адаптивны к реальности, где-то менее, отсюда и результат. Но метод настойчиво объясняет важность умения привлечь в команду профессионалов и работать «по схеме» и бесполезность надежды на успех дилетантов. Весёлые хипстеры, уверенно «нагибающие» транснациональные корпорации, рождаются только на съёмочных площадках Голливуда…
Публикация метода, надеюсь, также подводит черту под подзатянувшейся дискуссией на isicad о том, что можно жить по принципу «воровать чужие идеи и делать на этом успешную карьеру». Чтобы ворованная идея для вас стала эдаким «бустером», нужно украсть всю иерархию КИ с подробным описанием, при этом КВФ должны быть определены верно, а это значит, что ХМ должен совпадать как по структуре, так и по фазе, что всё вместе выглядит очень маловероятно... Ну украдёте вы резинку от трусов, а вам надо шапки шить. И что с этим будете делать?…
...Метод новый, продолжает развиваться на конкретных проектах. Кому интересна тема, пишите с рабочего адреса вот сюда: 352217@rambler.ru. Представьтесь, назовите должность и организацию, я отвечу.
Всем добра