Метаавтоматизация

Игорь Решетников, президент научно-производственного предприятия «Нефтегазсофтсервис»

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

Часто такие проекты заканчиваются тем, что оставляется все «как есть» и процесс просто прекращается. Это происходит потому, что с самого начала не был дан правильный ответ на вопрос: что же мы автоматизируем? Вопрос не такой уж и праздный, учитывая количество внедрений, которые не достигают результата. Не спешите утверждать, что «у нас все понятно». Ситуация несколько сложнее, чем кажется на первый взгляд.

Почему «метаавтоматизация»?

Начнем с постановки задачи. Правильно заданный вопрос — половина ответа. Правильно поставленная задача — половина успеха. Постановка задачи должна быть максимально формализованной и однозначной. Но в общем случае для систем корпоративного уровня этого невозможно добиться.

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

Поскольку охватить всю деятельность предприятия собственные ИТ-службы, к сожалению, часто не в состоянии, это самое описание деятельности выполняется внешними консультантами, в общем случае не ориентирующимися в бизнесе на нужном уровне и часто не знающими даже основ проектирования информационных систем. Этим порой грешат даже очень известные консалтинговые фирмы. Внешние консультанты проводят серию интервью с представителями бизнес-подразделений, часто очень поверхностных. Далее заказчику передается некая стратегия «оптимального построения корпоративной системы управления», которая на самом деле представляет собой не решение для данного предприятия, а просто существующий шаблон, лишь слегка адаптированный к текущему проекту. Формально придраться не к чему, в документе есть все: умные слова, современные технологии, лучшие мировые практики. А вот содержательная часть оказывается очень расплывчатой, в ней лишь прослеживаются пожелания опрошенных специалистов, но не более того. Этот документ берется за основу дальнейшего развития, и в результате автоматизация строится не на анализе множества входов и выходов системы управления, то есть не на реальной модели ресурсов, процессов, управляющих воздействий, а на описании мыслей и соображений о желаемых средствах и результатах. Даже целевое состояние автоматизации в таких документах крайне редко представляет собой сбалансированный и четко формализованный конечный результат. Как правило, это очень общие мысли без взвешенного анализа потребностей, возможностей и рисков.

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

Некоторые противоречия

Загадочное «покрытие бизнес-процессов»

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

Основных причин две: нет постоянной направленности на улучшение (стратегическая) и нет готовности объективно анализировать и описывать текущую ситуацию (тактическая).

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

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

Иногда интеграторы предлагают разработать систему, «которая делает все, что нужно», то есть в коммерческом предложении перечисляются абсолютно все виды деятельности из формального описания бизнес-процессов. Под такое громкое обещание начинается проект, даже появляется некая система, которая формально, по названиям модулей и отчетов, покрывает эти бизнес-процессы. Сделать это несложно, экранные формы в современных средах программирования рисуются очень быстро. В результате формально система вроде бы существует, даже числится на балансе, но фактически не работает: в систему не загружены данные, реальные бизнес-процессы не поддерживаются. И консультанты по формированию ИТ-стратегии зафиксируют ее как действующую, охватывающую почти все процессы. Им просто никто не даст написать другое, так как в этом случае надо будет кого-то наказать за зря потраченные средства. Ценность такой стратегии сразу становится нулевой, и бизнес-результатов она не принесет никогда.

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

Удивительно, что на большинстве таких предприятий есть (часто даже лицензионный) ARIS, но используется он лишь как графический редактор.

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

Рис. 1. Структура управляющих процессов

Откуда берется постановка задачи

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

• «Автоматизация нам поможет». Руководство неожиданно решает, что «хватит работать по старинке, внедряем информационную систему управления». При этом подспудно подразумевается автоматизация на основании текущей модели бизнеса.

Сразу вспоминается первый пароход Джона Фитча, в котором паровая машина приводила в движение весла, а весла приводили в движение пароход. Этот проект в XVIII веке был интересен как первая идея автоматизации мореходства. Но сегодня мы все прекрасно понимаем, что передача вращающего момента на винт (или колеса) гораздо эффективней. Но при этом новое эффективное решение данной задачи требует решения целого «букета» сопутствующих задач. Необходимо поменять тактику управления новым средством передвижения и стратегию его использования. Спроектировать размещение паровой машины и топлива. И т. д. и т. п.

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

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

• «Новый ИТ-директор». ИТ-подразделению необходимо продемонстрировать высокую активность. Удобнее всего начать с концепции информатизации предприятия. Этот документ необходим, но только в контексте бизнес-стратегии предприятия. Если он пишется «сам по себе» или стратегия не формализована, то его смысл теряется.

Разработка этого документа — очень выгодная строка бюджета. Никто и никогда ее не оспорит, никто не знает точно, сколько она стоит.

Свои специалисты ИТ-службы всегда очень заняты, поэтому, как правило, разработка концепции, поручается подрядчику. Далее все получается так, как было описано выше. У подрядчика есть свои накатанные решения, и он пишет концепцию, ориентируясь не на потребности заказчика, а на свои желания и возможности, превращая ее в прототип ТЗ на разработку системы. И чем больше (и красивее) он напишет, тем больше ему будет прибыли в будущем.

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

• «Это нужно бизнесу». Постановка задачи построения автоматизированной системы управления предприятием или некоторым процессом теоретически должна исходить от бизнеса.

Однако часто процесс постановки задачи выглядит, например, так. Руководитель бизнес-подразделения говорит: «У нас не хватает времени делать сметы по всем объектам, внедрите нам такую систему, чтобы сметы формировались автоматически». При ответе на вопрос «Есть ли четкие правила формирования смет?» выясняется, что для одного вида действительно есть (он всегда и приводится в пример). Обычно этот вид смет делается по шаблонам и не вызывает сложностей. Что касается остальных, то для них можно только получить образец реальной сметы. Стоит ли браться за такую задачу? Но руководство готово выделить серьезный бюджет для ее решения. И всегда найдется кто-то, кто будет готов его освоить. Однако этот проект обречен на неудачу. Иными словами, снова предлагается заняться метаавтоматизацией: задача сформулирована в основном в форме фантазий об автоматизации, высказанных представителем бизнес-подразделения, но нет понимания требуемой задачи управления.

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

На практике автору довелось столкнуться с ситуацией, когда в достаточно крупной компании ИТ-директор не внедрял никаких систем (кроме кадров и бухгалтерии), потому что полного совпадения заявленных возможностей со своими требованиями не находил. В результате в бизнес-подразделениях «расплодилось» множество локальных систем, которые хоть как-то помогали работать. После того как ИТ-директора сменили, ситуация стала немного исправляться, но очень медленно. Любые изменения встречали сильное сопротивление, потому что у каждого сотрудника уже была любимая и привычная система. Надо ли говорить, что все процессы в этой компании были оторваны друг от друга и подразделения работали практически изолированно, часто дублируя функции друг друга.

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

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

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

Каждое предприятие уникально

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

Анализируя особенности своего предприятия, не следует забывать, что в блоке управляющих процессов всегда есть «кормчий» процесс (см. рис. 1), под который все остальные процессы подстраиваются (см. С. Бир. Наука управления. М.: ЛКИ, 2010). Это может быть связано с узким местом, человеческим фактором, действующими регламентами и т. п. Например, на одном машиностроительном предприятии все строится на идеальной проработке техпроцессов и нормировании, а на другом, очень похожем, на идеально организованной диспетчеризации. В этом случае в первом варианте диспетчеризация оказывается ведомым процессом, а во втором — ведущим. Если внедряемая информационная система не может оперировать показателями этого «кормчего» управляющего процесса, то эффективного управления всем производственным процессом в комплексе не добиться.

Любая крупная информационная система должна внедряться на предприятии, опираясь на задачи как минимум трех участков (задач, направлений и пр. — в зависимости от масштабов), причем по меньшей мере два из них должны быть ключевыми. Такое ограничение, с одной стороны, позволит выбрать подходящую систему на рынке (чем больше ограничений, тем сложнее выбор), а с другой стороны, обеспечит устойчивый базис для управления всем производственным процессом.

Так, в модели MESA систем производственной автоматизации выделено восемь функций. Из практики известно, что системы, которые покрывают менее трех функций, не приживаются и не дают нужного эффекта. За очень редким исключением.

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

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

ИТ-директор — лидер перемен

Разобранные выше проблемы во многом связаны с неправильным позиционированием ИТ-департамента. Он должен быть ориентирован на поддержку основного бизнеса, а не ИТ-инфраструктуры. Вследствие этой ошибки предъявляются неправильные требования к руководителю ИТ-службы, и в результате от нее нет бизнес-отдачи. Чтобы этого избежать, надо вовлекать ИТ-директора в управление организацией, определять его бонусы на основе бизнес-показателей всего предприятия. Только тогда он станет лидером перемен в бизнесе. А до этого управляемое им подразделение будет жить своей собственной жизнью, планомерно осваивая выделяемые бюджеты.

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

Заключение

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