Тонкие грани
Автор
Игорь Решетников
Трудозатраты на написание хорошего ТЗ могут оказаться соизмеримыми с разработкой самой системы
Иногда кажется, что все вокруг просто помешались на формализации и регламентации всего, что только возможно и невозможно. И ИТ не исключение, увы. Тонны регламентной и нормативной документации, толстенные SLA, протоколы совещаний, многоуровневые требования к системам и т. д. и т. п. Да, естественно, системы становятся все сложнее и сложнее. Но все-таки всегда ли оно того стоит? И не теряется ли за этой макулатурой сам смысл процесса?
К великому сожалению, так оно зачастую и происходит. Попытка формализовать как можно лучше убивает саму идею, смысл и суть автоматизации. Пользователи тихо уходят в Exel, а ИТ-служба и привлеченный исполнитель начинают, сами того не замечая, просто играть в автоматизацию.
Вот ведь что получается: сначала придумали автомобиль. Потом решили, что надо сделать его безопасным для всех и удобным. Установили несколько правил дорожного движения. Потом еще несколько. Потом ввели ответственность за их соблюдение. Потом сделали службу, которую громко назвали службой обеспечения безопасности и удобства, а на деле — службу контроля исполнения правил дорожного движения. А ведь это отнюдь не одно и то же.
Почему же формализация не всегда есть польза для общего дела? Ведь, как доказала теорема Гёделя, даже такая, казалось бы, суперформальная наука, как математика, не является 100% формализуемой.
Проектируем систему
Итак, начинаем с проекта. Казалось бы, чего проще? Все стандартно и накатано: пишем техническое задание — и вперед! Вот тут и начинается загвоздка: насколько детальным оно должно быть? Правильный вопрос — практически готовый ответ, то есть трудозатраты на написание хорошего ТЗ могут оказаться соизмеримыми с разработкой самой системы.
Когда, например, внедряется бухгалтерская система на базе существующего плана счетов, то есть задача формализована и эта формализация должна найти свое отражение в проектируемой системе, все выглядит более или менее понятно. А вот когда организация работает по некоему набору регламентов, написанных в отсутствие какой-либо автоматизации, ситуация становится совсем печальной.
Типичный, увы, путь — положить существующий регламент в основу проекта. Это тупик. Смысла автоматизироваться нет. Если регламенты есть и по ним ведется работа, то пусть она и ведется. Автоматизация ничего не даст. Точнее, приведет к потере веры в саму идею автоматизации и к неоправданным финансовым затратам. Но отойти от регламента нельзя, поскольку он является документом, обязательным к исполнению. Круг замкнулся.
Редкое исключение, когда в регламенте присутствуют некие рутинные функции, которые можно точечно покрыть локальными (или глобальными) системами. Тогда эффект хоть какой-то будет, но в этом случае не надо делать вид, будто автоматизируется весь процесс. Надо признавать, что процесс не трогаем, а делаем лишь некие полезные подсобные инструменты.
Попробовать «спросить у бизнеса»? И что вам этот самый «бизнес» ответит? Процитирует регламент в лучшем случае. В худшем — нафантазирует что-то, совсем далекое от реальности. Ведь для них главное средство автоматизации — это Excel. Они мыслят его возможностями и категориями. Вы даже, скорее всего, получите от них кучу требований сделать вот так и вот так, с приложенными экранными копиями электронных таблиц.
Пригласить некоего системного интегратора, веря фантастическому лозунгу, что он сейчас проведет обследование и интервьюирование и все сделает в лучшем виде? Почему-то (особенно часто в крупных компаниях) таким обещаниям верят больше, чем собственным специалистам. А в результате получаем проект, по которому лучшим продуктом для построения системы является именно тот, которым торгует данный интегратор. Странно, не правда ли?
Следует сделать одну оговорку: есть (хотя их крайне немного) интеграторы действительно великолепные профессионалы в своей области. Они обладают реальными знаниями и опытом, сравнимым с вашим. К тому же у них есть больший кругозор и возможность взглянуть на проблему со стороны. Они смотрят в корень и понимают суть, здравый смысл у них на первом месте. Если вы нашли такого интегратора, то вам невероятно повезло.
Что еще? Пригласить внешнего консультанта. Иногда работает. Но консультанты бывают двух видов — одни послушно пишут в документы то, что им диктуют. И потом на основании этого требуют подписать акты. Другие накладывают на ваше предприятие некую эталонную модель бизнес-процессов, вступая в противоречие с действующими регламентами. Сложить и то и другое, как правило, не получается по миллиону факторов. Дальше возможны варианты: либо перестраиваем бизнес, либо см. выше по тексту.
То есть получается: вроде бы всем понятно, что должна делать организация и чего хочется от автоматизированной информационной системы. А на практике все выливается в попытку описать это как можно более детально, на что тратится много сил и времени. А результат оказывается слабо востребованным на следующих этапах жизненного цикла системы.
Что делать? Немного включить здравый смысл и подумать, зачем мы проектируем систему. Ради чего мы это делаем? А значит, надо выбрать измеримый показатель (или несколько), измерить его сейчас и поставить цель, к которой его нужно привести в будущем. Указав, в каком конкретно будущем. В принципе, от проекта системы большего и не требуется. Все остальное — технические тонкости.
Выбираем подрядчика
Следующий шаг — выбрать правильного подрядчика. Такого, чтобы по созданному проекту сделал то, что нужно в указанный срок, с оговоренным результатом и выделенным бюджетом. Бюджет, кстати, должен формироваться не на основе сметы интегратора, а на основе анализа того, что это принесет вашей компании.
Типичный пример процесса выбора: готовим конкурсную документацию, запрашиваем предложения, выбираем лучшее. Просто и эффектно. Только вот когда покупают бумагу для принтера — это понятно: минимум цены плюс максимум сервиса. А в случае проекта? Представьте, что вы решили сделать сложную операцию, от которой зависит ваша жизнь. Вы сделает так же? Соберете предложения от 10 больниц и по минимуму цены и максимуму обещаний выберете хирурга? Нет, вы изучите варианты, репутацию, статистику, отзывы. И сделаете осознанный выбор.
При этом заметьте, никаких формальных требований вы никуда записывать не будете. В данном случае вы выбираете для себя, для вас важна суть. Здравый смысл на первом месте. И только он. Даже список того, академиком каких мировых академий является тот или иной доктор, на вас не произведет никакого впечатления.
Примерно так же стоит подходить и к выбору подрядчика. Изучить репутацию, результаты, опыт, наконец, просто поговорить с его специалистами. Автоматизация производственных процессов — это не стройка в формальном понимании, это каждый раз НИОКР, который в процессе может неожиданно развернуться и пойти совсем другим путем. Главное, быть уверенным, что до цели дойдем.
Как часто получается? Чтобы избавится от недостаточно квалифицированных подрядчиков, начинают вводить некие формальные требования. Со временем их становится столько, что удовлетворить им могут только специально созданные для удовлетворения этих требований компании. Делать они ничего не умеют и не могут, они могут и умеют хорошо удовлетворять любым требованиям. Их бизнес заключается именно в этом. И попробуйте потом не подписать им акты выполненных работ. Нужен такой подрядчик? Вряд ли.
В общем, самый лучший выбор — адекватный подрядчик, такой, который готов к любым поворотам проекта и понимает ваш бизнес и цель проекта. А не тот, у кого громкое имя, сотни сотрудников или офис в «Москва-Сити». Неужели у вас такого нет? За годы работы, в результате естественного отбора, наверняка есть.
Внедряем систему
Итак, есть проект или понимание того, что должно получиться, есть подрядчик, есть бюджет. Осталось внедрить (разработать, доработать, сконфигурировать, установить и т. д.) нужную систему. Вот тут-то и начинается самое интересное. Непонятно почему, но все думают, будто надо взять в руки PMbok и сразу будет успех и много счастья. Не будет. Будет много потерянного времени, лишние затраты и невнятный результат. Вообще, проектное управление в состоянии убить любой проект по производственной автоматизации, об этом чуть выше уже говорили.
Особенностью производственной автоматизации, в отличие от других типов систем, является то, что в них все КПЭ относятся не к самому процессу автоматизации, а к основному производственному процессу. То есть с точки зрения процесса внедрения системы всё выполнено в соответствии с уставом, все совещания проведены, все этапы пройдены. А эффекта нет. При внедрении документооборота, например, такого быть не может. А в задачах автоматизации производственных процессов — сплошь и рядом.
Это совсем не личная точка зрения автора, это, как ни парадоксально, нормальная мировая практика. Руководства ассоциации MESA, например, дают четкие рекомендации по организации процесса внедрения: этапность, от малого к большому и т. д. Не будем их все здесь приводить. Их легко найти и с ними ознакомиться. Все рекомендации, которые там даются, звучат как банальные истины для учеников начальной школы. И из-за этого их очень часто не воспринимают всерьез. А зря. Это позволило бы избежать массы ошибок и вместо многолетнего «долгостроя» обеспечить процесс внедрения четко, маленькими шагами и с реальным, а не «бумажным», результатом.
Подводя промежуточный итог, хочу сделать акцент на главном: никогда за процессом не забывайте цель, изучайте и применяйте мировой опыт по системам именно того класса, который вы хотите внедрить, не верьте тому, в чем не видите смысла и пользы, не тратьте ресурсы на излишнюю отчетность и презентации. Лучше потратьте их на дополнительную функциональность.
К сожалению, регулярно попадаются различные документы, как правило, крупных структур, в которых столбцы «как надо» и «как не надо» перепутаны местами, если сравнивать с тем, что говорит мировая практика, что говорят люди, которые это уже прошли. Часто это происходит даже не по злому умыслу, а просто из-за банального незнания и некомпетентности людей, разрабатывающих и, что самое страшное, воплощающих в жизнь такие проекты. Губится время, деньги, вера в пользу автоматизации. Поэтому внедряйте правильно.
Сопровождаем систему
Итак, система сделана, внедрена, сдана в промышленную эксплуатацию, стала востребованной, нужной и критичной для бизнеса. Критичность — это, образно, когда после выключения сервера производство через три часа останавливается. Допускать такой ситуации нельзя — будут баснословные денежные потери, поэтому нужен процесс сопровождения системы.
На самом деле сопровождение — это не просто поддержание работоспособности системы и регулярная чистка сервера пылесосом. Это процесс постоянного поддержания функциональных возможностей системы на требуемом для производственного процесса уровне. Соответственно, данный процесс куда шире, чем просто регулярное обновление версий программного обеспечения и установка «патчей». В подобный процесс входит, например, участие в подготовке спецификаций на новое оборудование, которое предприятие готовится приобрести, если после закупки оно должно быть подключено к существующей системе. Это верно, например, для систем класса MES.
Иными словами, процесс начинается не после того, как оборудование привезли, установили, а потом сказали: подключайте его в систему. А тогда, когда принимается стратегическое решение о покупке. На этом этапе следует сформулировать требования к коммуникационным возможностям нового оборудования, определить протоколы обмена, запланировать работы по проведению нужной сети передачи данных (Ethernet это не единственное, что бывает в природе) к месту будущего его размещения, все протестировать и сделать виртуальное устройство в системе, включить его в производственный процесс начиная с даты запланированного ввода в эксплуатацию.
И все это тоже процесс текущего сопровождения. Совершенно неважно, делается он собственными силами или внешним подрядчиком. Установленное оборудование должно начать использоваться с даты ввода в эксплуатацию. А не через два месяца, когда его подключат к системе. Именно это и является критерием правильно построенной сервисной поддержки. И если коммуникационный модуль ожидается на 10 дней позже самого станка, значит, срок ввода должен быть заранее скорректирован.
Естественно, никто не отменяет обслуживание серверов, обновление ПО и т. д. Но об этом помнят все, а вот про суть системы часто забывают, и при актуальных версиях ПО и резервированном сервере с избытком вычислительной мощности процесс разваливается на нормальный и внесистемный. Такого быть не должно, и именно это и должно стать основным требованием к сервисному подразделению. А не многостраничные SLA с регламентированным временем ответа на звонок и прочие подобные формальности. Это не массовый сервис, а единичный и высокотехнологичный. SLA, даже самые гениальные, тут бесполезны. Только здравый смысл, идущий от потребностей.
Кто за чем бежит?
Если к этому моменту у вас сложилось впечатление, что идет агитация за полный отказ от формальностей, это не так. Формальности нужны. И регламенты нужны. Процесс должен быть формально описан. Главное — все должно быть как в хорошей книге, то есть все по делу и с одинаковой детализацией. Хороший документ — относится ли он к стадии проектирования, внедрения или сопровождения — должен четко отражать цель всего проекта. Не формальную и лозунговую, вроде «повышение качества управленческих решений», а ясную, измеримую и выраженную в показателях производственного процесса. Тогда становится понятным КПЭ всего процесса внедрения системы.
И лишь в том случае, когда заказчик, инвестор, подрядчик, пользователь, сопровожденец видят эту цель и идут к ней, только тогда гарантирован успех. К великому сожалению, в жизни всё совсем не так, а как-то совсем невнятно: заказчик хочет счастья, то есть неожиданного решения всех проблем после внедрения системы; инвестор — дополнительной прибыли из ниоткуда; подрядчик — продать побольше лицензий и услуг и сдать проект в соответствии с ТЗ точно в срок; собственная ИТ-служба хочет в срок освоить бюджет и отчитаться об этом; пользователь просто не хочет лишних проблем; сопровожденец — представить отчет о сотнях часов консультаций и выполненных работах и подписать его. Лебедь, Щука и Рак по сравнению с этой компанией просто эталон единодушия.
Автоматизация производственных процессов — командная работа. У каждого тут своя четко определенная роль, как в футболе. Но цель одна — забить как можно больше голов и пропустить как можно меньше. Тренер строит стратегический план, распределяет роли, и дальше каждый должен выработать тактику на своем месте, чтобы стать максимально полезным. Не чтобы точно выполнить то, что написано «там-то», а именно быть максимально полезным с точки зрения цели. Бывали случаи, когда и вратари забивали гол противнику, в жизни случается все. Или почти все.
Данный проект — ваша зона ответственности? Сделайте так, чтобы все бежали к одной цели, и успех вам обеспечен.
Опубликовано 29.11.2013