ИТ на ядерном топливе
Автор
Макс Волк
,
Ольга Попова
Поддерживать несколько «маленьких» систем в какой-то момент становится дороже, чем одну «большую».
Алексей Часников, руководитель Центра экспертизы САП компании «Мечел», гордится своим прошлым физика-ядерщика. И ИТ-проекты в его руках сродни управляемой ядерной реакции — реализуются с соблюдением необходимых мер безопасности, дают много прибыли и тепла. Главное — все хорошо продумать вначале и никогда не ввязываться в «драку» с внедрением, руководствуясь принципом «главное начать, а там посмотрим».
Кто же вы — физик или лирик?
Если вкратце, то перед вами физик, сменивший извлечение практической пользы из законов природы на оптимизацию практики управления бизнесом. В 1994 году я получил степень MBA и стал работать как бизнес-консультант. Сначала в Deloitte, откуда после нескольких крупных проектов под патронажем USAID перешел в российскую фирму, затем был небольшой период, когда я работал финансовым директором Национального фонда развития промышленности. Для меня это была новая, интересная задача. Но дело было перед кризисом 1998 года, и я вернулся в Deloitte где участвовал в проекте перехода с третьей версии системы Scala на пятую, который включал реструктуризацию и автоматизацию финансовых функций 16 компаний в СНГ и за рубежом, с разными стандартами учета. Это была отличная школа по проработке ИТ-проекта с нуля до завершения, и даже дальше — использования внедренной системы в качестве потребителя ИТ-услуг.
Но именно с 98 года я плотно занялся ИТ. До этого превалировал управленческий и финансовый консалтинг. А через 7 лет снова ушел, на сей раз на производство. Так и пошло — реализация накопленного опыта в нескольких производственных компаниях, затем стратегический бизнес-консалтинг в компании SAP, откуда перешел опять в производство, в «Мечел», где сейчас руковожу центром экспертизы.
Ну а что касается лирики, то каждый проект, это как новая поэма - у каждого своя муза, свои положительные и отрицательные герои .
По научной деятельности не скучаете?
Я ее не бросал — в активе и научные статьи в области радиационного материаловедения и приборостроения, пособия по планированию и финансовому менеджменту, участвовал в подготовке «Учебника 4 CIO». К тому же имеется публицистическая книга и статьи по вопросам радиационной экологии. Такой вот «научный» набор.
С чем связана ваша деятельность в «Мечел»?
Начну с того, что «Мечел» — крупный российский горно-металлургический холдинг. Компания объединяет большую группу предприятий в разных станах. Моя профильная деятельность здесь связана с управлением проектами, организацией сопровождения и поддержки внедренных ИТ-систем, модернизацией процессов управления ИТ и т. п.
Для этого обязательно создавать на предприятии Центр экспертизы?
Иногда людям кажется, будто центры экспертизы — это что-то навязанное вендором. Но я убежден: SAP прививает заказчикам совершенно правильную идею о том, чтобы на предприятиях были эксперты, знающие методологию внедрения и особенности обслуживания и функционирования ИТ-систем, и не только на базе ПО SAP. В контрактах, где определяются общие условия поддержки и сопровождения, черным по белому написано, что должен быть центр экспертизы. И это как раз то, что можно отнести к «лучшим мировым практикам», поскольку при правильном подходе именно такие центры экспертизы, их еще называют центрами компетенций, делают успешным не только внедрение, но и дальнейшую эксплуатацию ИТ-решений.
Вы сталкивались с тем, что многие свои проблемы бизнес пытается свалить на ИТ — то результатов нет, потому что нет ИТ-системы, то потому, что ПО купили не то?
Есть старая хорошая поговорка: «Спасение утопающих — дело рук самих утопающих». Айтишник реализует замыслы руководителей, владельцев бизнес-процессов, внутренних бизнес-заказчиков. Сваливать проблемы на ИТ легко.. Но здесь очень многое зависит от бизнес-пользователей, и в первую очередь — готовы они принимать внедренную программу или нет. Есть отдельная большая задача — управление организационными изменениями, и она играет огромную роль в обеспечении успеха проектов внедрения информационных систем. Если люди не готовы к переменам, они активно или пассивно сопротивляются проекту. И все свои ошибки, а также нежелание работать действительно сваливают на «неудобное» ПО.
Является ли внедрение управленческого ПО сигналом к смене команды?
Нет. Менять имеет смысл тех, кто не выдерживает жестких условий проекта, потому что в проекте надо работать, работать вдумчиво и на совесть. Те члены команды проекта, кто не готов к такому режиму, не выдержат перехода на новую систему. С такими людьми действительно приходится расставаться.
И айтишнику, и бизнес-заказчику проекта важно собрать команду, которая тебя поддерживает. Если взглянуть на статистику, то на старте проекта за внедрение выступает обычно около 20% персонала. Половина штата колеблется, а оставшиеся 30%, обычно занимают негативную позицию.
При правильном управлении процессом часть противников постепенно переходит на сторону внедренцев. Как только достигается критическая масса и сторонников становится примерно 35–40%, начинают подтягиваться все колеблющиеся. Но те, кто радикально против, могут уйти.
Зачем вообще менять управленческое ПО?
Времена меняются, и мы меняемся вместе с ними — так говорили древние. Смена законодательства — один из стимулов модернизации бизнес-приложений. Второй важный фактор – изменение старых или появление новых бизнес-процессов, которые должны быть автоматизированы. Кроме того, компании-разработчики не стоят на месте. Выходит новое ПО, с новыми функциями, а старое вендоры перестают поддерживать. Скоро, к примеру, перестанет поддерживаться версия SAP 4.7. По 1С версии 7.7 уже поддержка прекратилась. Это перманентный процесс, за ним нужно следить и принимать соответствующие меры.
Переходить на новую версию — это одно, а зачем менять платформу?
Такого рода переход не форс-мажор, а обычная работа ИТ-руководителя. Ему приходится переводить ИТ-систему с одних бизнес-процессов на другие. В ходе развития предприятия сначала происходит переход с самописных систем на промышленные, затем — с одной промышленной платформы на другую. Замечу, что последний вариант перехода гораздо проще, чем первый. Дело в том, что самописные решения разрабатываются по своим местечковым стандартам и переход с них на общепринятые связан порой с серьезной перестройкой ИТ-процессов и бизнеса всей компании.
На решения крупных мировых вендоров — Microsoft Axapta, Oracle или SAP — могут переходить компании, которым требуется собрать в одном месте больший объем информации. Те, кто работает на локальных решениях, в процессе развития вынуждены докупать разные модули — CRM, BI, Supply Chain Management — от разных фирм. В крупных системах все это «зашито внутри». Проще говоря, переход от более простых систем к сложным обусловлен зачастую тем, что люди хотят собрать все данные в одном решении, организовать единое информационное пространство и уйти от ошибок двойного ввода, несопоставимости управленческих отчетов из разных систем.
И от содержания в штате специалистов по разным решениям?
Совершенно верно: поддерживать несколько «маленьких» систем в какой-то момент становится дороже, чем одну «большую». Платить зарплату большему количеству людей, пусть даже с более низкой квалификацией — не всегда выгоднее. Есть мнение, что SAP будет всегда дороже в поддержке, чем много «маленьких» дешевых систем. И это будет так, если не задуматься о поддержке еще во время внедрения.
Типичная ошибка — реализация в проекте всех «хотелок» представителей разных подразделений. При этом нередко забывают, что при обновлении версии, все «хотелки» придется правильно переносить. И горе той компании, где программист внес существенное количество несогласованных изменений и не оставил грамотно задокументированной информации о них. Да, у стандартного решения свои рамки. Но может быть, стоит обдумать, в каких моментах подделывать систему под бизнес-процессы, а в каких — наоборот.
Как продумать заранее поведение пользователя, чтобы учесть это при разработке интерфейса?
Смотреть на задачу под разными углами — иногда даже психологов привлекают, чтобы оптимизировать эргономику интерфейсов. Если, к примеру, сотруднику во время общения с клиентом или другим сотрудником надо переключаться между 14 экранами, он попросту не сможет говорить, отвечать на вопросы. Понятно, что такая система окажется неудобной. Обилие новых функций тоже нередко пугает людей, вызывает отторжение. Все это приходится учитывать.
Но как же Big Data — жажда управленцев анализировать гигантские потоки данных?
Представьте себе летчика-испытателя в кабине истребителя. Он может управлять одновременно не больше чем 14 параметрами. И это асс. Стандартный пользователь управленческой системы может одновременно контролировать три-четыре параметра. Талантливый руководитель держит в уме от 9 до 10 параметров. Когда на любого человека сваливается дополнительный объем информации — это плохо. Люди пытаются найти обоснование новым данным, теряются, теряют время.
Здесь надо использовать категории необходимости и достаточности. Какая информация нужна, как ее получить и как использовать? Вот три вопроса, важнейшие для разработчика баз данных и для разработчика бизнес-стратегии. Если на предприятии нет четкого понимания процессов управления информацией, люди будут использовать разную информацию, формировать разные отчеты, делать взаимоисключающие выводы по одним и тем же событиям.
Есть еще один аспект — нежелание отказаться от старого. В процессе проработки процедур подготовки отчетности нередко пытаешься доказать, что при наличии нового отчета старый становится не нужен. В ответ: «А мы его всегда делали, нельзя нам без него, некомфортно!» Проще говоря, одной из задач управления организационными изменениями будет перестроить отношение управленца к информации, к тем процессам, которые должны быть, вместо тех, которые есть.
В облаках перепрыгивать с платформы на платформу легче?
Строить свой дом, а затем его перестраивать, конечно же, сложнее, чем переехать из одной съемной квартиры в другую. В этом плане у облаков может быть большое будущее, но компании, пользующиеся облачными приложениями, должны по максимуму стандартизировать свои бизнес-процессы. Минимизировать количество «хотелок».
Если мы еще не допрыгнули до облака и внедряем какую-то систему у себя, то кого набирать в проектную команду?
«Если парень в горах — не ах, ты его не брани — гони». Подходит лишь тот, кто готов выделить проекту свое время, будь то айтишник или бизнес-специалист. Если удается набрать необходимое количество таких людей, то проект будет выполнен в срок. С высоким результатом, но это не значит, что не будет авралов.
Важно также, чтобы у проекта был нормальный спонсор, который не просто дает деньги и покрикивает, но и помогает разруливать тяжелые ситуации. Естественно, у команды должен быть нормальный лидер и хорошо проработанный план подготовки проекта внедрения информационной системы, его реализации и последующей передачи готового решения в поддержку и сопровождение. И должна быть система информирования в проектной команде, показывающая, кто чем занят, кому требуется в данный момент «подставить плечо».
Кроме того, нужно на раннем этапе привлекать в команду специалистов, которые будут поддерживать систему после внедрения. Чтобы они сразу начинали понимать, с чем им придется столкнуться.
Нужны ли проектной команде спецы по модным технологиям?
Все технологии нужно сначала продать ключевому бизнес-заказчику. Если вы придете к вице-президенту по финансам и скажете: «Я хочу сделать такое новшество, оно принесет компании столько-то денег» — то руководитель вас поймет. А если скажете: «Я хочу сделать вот это, потому что это ново и прогрессивно, и мне надо столько-то» — он ответит: «Не убедил». Все новинки «высоких» технологий должны вначале быть детально описаны и протестированы. Если, например, указаны требования по «мобильности», то проектная команда, используя «спецов по модным технологиям» должна проработать все за и против, оценить возможности их применения в реалиях доступности операторов связи, и только потом их реализовать.
Нужны ли тендеры?
Нужны. В любом случае. Когда у вас есть несколько похожих решений разных вендоров, каждый из которых говорит, что его ПО полностью соответствует запросам, вам нужно не просто выбрать, вам необходимы методология оценки, обоснованные критерии отбора, обработанные согласно методикам и критериям данные от вендоров или поставщиков услуг по внедрению, подтверждающие документы и результаты референс визитов.
Как-то мне на одном тяжелом тендере задавали вопрос о том, что будет, если один из участников конкурса слегка слукавит и напишет, что система делает все, что нужно, вопреки истинному положению дел? Я ответил, что после тендера у меня будет документ, с которым я приду к подрядчику и скажу: «Теперь делай все, что тобой написано, за те деньги, которые указаны, а лишних я тебе не заплачу. А если не сделаешь, как обещал, то я буду вынужден сделать так, чтобы о твоем лукавстве узнал весь рынок». Это сработало. Предложение с тендера сняли.
Кроме тендерной документации есть и реальный опыт коллег. Как узнать о негативном опыте, если СМИ о нем не пишут?
Надо смотреть не только на цену внедрения, функционал, успешный и неуспешный опыт, но и на совокупную стоимость владения и соответствие ожидаемых и полученных результатов. Кроме того, если затраты на поддержку и сопровождение постоянно увеличиваются, а неудовлетворенность пользователей не снижается, то вряд ли внедрение может быть признано удачным. Среди коллег в нашем клубе ИТ-директоров сравнивать эти моменты проще. Всегда найдется тот, кто наступал на какие-то грабли и готов поделиться опытом. Но на чужой негативный опыт надо смотреть с «холодным сердцем» и через призму своих внедрений. Не исключено, что человека могли просто обидеть, и он в сердцах скажет о вендоре нечто нелицеприятное.
И тогда риск негативного результата будет нулевым?
Риск того, что проект будет неудачным, есть всегда. Мало того, исследования аналитиков показывают, что количество неуспешных внедрений в последнее время растет во многих странах. Я полагаю, что кроме усложнения бизнес-процессов и экономических причин, одним из факторов является общее снижение дисциплины выполнения проектов.
Как избежать этого? Семь раз отмерь, один раз запрограммируй. Надо изначально прописать все шаги проекта и ожидаемые результаты. И никогда не следовать принципу «давайте ввяжемся в драку, а там посмотрим». Эта позиция не выигрышна ни для заказчика, ни для поставщика. С высокими технологиями все, как и с высокой кухней, — самый хороший продукт можно загубить. Все зависит в итоге от поваров, от того, насколько люди вкладывают душу в свою работу.
Опубликовано 25.03.2013