В настоящее время на рынке существует огромное множество IT-решений, предназначенных для автоматизации различных процессов на предприятии. Разработчики, предлагающие такие решения, наперебой утверждают, что внедрение их систем позволит владельцам существенно сократить издержки, увеличить объемы прибыли и поднять качество выпускаемой продукции или услуги.
Руководитель, принимая решение о необходимости автоматизации того или иного процесса в своей компании надеется, что в результате такого внедрения все имеющиеся ранее проблемы пропадут и наступит "счастливое Завтра". Торговые представители резко увеличат объемы продаж, а отдел закупки будет приобретать именно те товары, которые востребованы и именно в том количестве, которое необходимо для поддержания оптимального товарного запаса. Склад, безусловно, начнет быстро принимать поставки, заказы Клиентов будут комплектоваться оперативно и безошибочно, а отдел доставки передаст товар клиенту строго в указанное время. Надежды остаются несбыточными мечтами, "Завтра" наступает, а существовавшие ранее проблемы остаются, усиленные необходимостью работы с новой информационной системой, которая "только мешает заниматься делом". Почему же так происходит?
Как правило, технология, имеющаяся у Заказчика на момент начала проекта, не формализована и базируется на знаниях отдельных исполнителей или менеджеров нижнего уровня. Сами исполнители не имеют никакого представления о программном обеспечении, которое планируется к внедрению, и даже о самой идее автоматизации знают понаслышке. В свою очередь, менеджер проекта (или бизнес-аналитик) со стороны Исполнителя, владеет только той технологией, которая заложена в программном продукте, и даже не предполагает о возможности существования особенностей, которые не могут быть автоматизированы с помощью внедряемого программного обеспечения без существенных доработок. От того сможет ли этот специалист, за короткий период предпроектного исследования, общаясь с менеджерами среднего или высшего уровня, изучить все особенности технологического процесса Заказчика, определить саму возможность автоматизации и выбрать ее правильную схему, зависит результат проекта. Достаточна ли его квалификация для решения столь ответственной задачи? Такая ли задача поставлена перед ним? – вопрос, в ответе на который Заказчик совершенно напрасно полагается на Исполнителя.
В любом программном продукте, заранее заложена определенная бизнес-логика, которая никогда полностью не совпадает с той технологией, которая принята в компании на момент внедрения программного продукта. Таких отличий может быть много или мало, но они обязательно имеются. Прекрасно, когда такие отличия касаются процессов, которые уже есть в вашей организации, но построены нерационально. Нет ничего страшного, если приходится вносить изменения, даже очень большие, в имеющуюся технологию, которая не влияет на конечный результат. Проблемы наступают тогда, когда для внедрения программного продукта приходится добавить новые операции, требующие дополнительные временные и человеческие ресурсы. Еще хуже дело обстоит, когда приходится изменять или вовсе избегать операции, наличие которых создает ключевое преимущество компании. Зачастую, Заказчик не имеет возможности до начала реализации проекта, а во многих случаях до начала этапа внедрения, правильно оценить необходимость вышеуказанных изменений, их стоимость и последствия для бизнеса. Ведь в процессе предпроектного исследования Исполнитель пишет технические задания, согласовывая их с Заказчиком, при этом описание технологии работы персонала и описание взаимодействия с информационной системой (инструкция пользователя) оказываются либо за рамками проекта, либо передаются Заказчику на этапе внедрения. При этом в техническом задании, написанном представителями Исполнителя, узкие моменты оказываются либо незатронутыми, либо сведенными к ни чему не обязывающей фразе: «выполняется в соответствии с технологией, заложенной в поставляемое программное обеспечение».
В результате Заказчик оказывается в ситуации, когда приходится идти на изменение стоимости проекта за счет дополнительных доработок, увеличение эксплуатационных затрат для выполнения требований новой технологии, отказываться от своих особенностей, зачастую важных для Клиентов или оставлять целые блоки технологического процесса без автоматизации.
При внедрении готового программного продукта Заказчик обязан четко понимать, что он не автоматизирует собственные технологии, а изменяет свои технологии под те, которые заложены во внедряемом программном обеспечении. Приняв такой подход, очень быстро возникает понимание того, что с Исполнителем, в первую очередь, должны обсуждаться и согласовываться не технические задания на модернизацию программного обеспечения, а изменения, которые будут вноситься в технологический процесс работы предприятия. Должны быть четко определены те процессы, которые автоматизируются без изменений и те, что остаются без автоматизации, какие полностью убираются из технологической цепочки, какие добавляются, а какие требуют глубоких изменений.
Именно в начале проекта должны появляться новое штатное расписание и новые должностные инструкции, в этот момент необходимо начинать разрабатывать новую систему мотивации персонала и по мере возможности вносить изменения в существующие процессы с целью приближения их к новой технологии.
Еще одной, на мой взгляд, глобальной ошибкой Заказчика является желание автоматизировать существующие на предприятии процессы, а не изменять их на качественном уровне, используя возможности, предоставляемые современными информационными технологиями. Об этом очень наглядно было продемонстрировано основоположником реинжиниринга Майклом Хаммер в его книге «Реинжиниринг корпорации» в давнем 1993 году. И он на 100% прав, утверждая, что «автоматизировать существующие процессы с помощью IT – все равно, что асфальтировать протоптанные коровами дорожки». С тех пор многое изменилось, но указанная проблема является актуальной и сегодня, спустя 20 лет.
Перед началом автоматизации, Руководителю необходимо четко осознать те процессы, по которым в настоящий момент работает его предприятие, переосмыслить их необходимость и рациональность, определить необходимые изменения и только после этого определять способ автоматизации новой технологии. А выбор, в общем-то, невелик: находить готовое программное обеспечение и адаптировать под него свои технологии; заниматься глубокой модернизацией существующего программного обеспечения; создавать программное обеспечение, целиком предназначенное для достижения поставленной перед проектом цели.
Необходимо помнить, что при правильном подходе, вносимые изменения неизбежно выходят за границы существующих зон ответственности структурных подразделений предприятия. Делегирование полномочий на проектирование и внесения таких изменений менеджерам среднего и нижнего уровня, пагубно влияет на реализацию проекта автоматизации. Происходит это по следующим причинам:
- руководители среднего и нижнего уровня не обладают необходимой широтой взглядов на деятельность предприятия;
- их авторитета, зачастую, не достаточно для продвижения изменений за пределами зоны их ответственности;
- вносимые изменения могут привести к существенному уменьшению их влияния в дальнейшем, и поэтому они могут быть не заинтересованы в реализации проекта и направлять его в сторону от правильного пути.
Для успешной реализации проекта автоматизации внутренних процессов предприятия у проекта в обязательном порядке должен существовать куратор из числа руководителей предприятия верхнего уровня (директор по развитию, заместитель генерального директора и т.п.), ответственный за обеспечение проекта ресурсами и осуществляющий административную, финансовую и иную поддержку проекта. Подотчетным ему является менеджер проекта, который осуществляет планирование, контроль и управление проектом и проектной группой, создаваемой ему в подчинение, которая в свою очередь и будет проектировать новые технологии, разрабатывать необходимую документацию, изучать имеющиеся на рынке способы автоматизации, водить в эксплуатацию новое оборудование, проводить найм, сокращение и обучение персонала и т.д. и т.п.
При этом участники группы проекта должны обладать, не только соответствующими знаниями и опытом, но и временем для участия в проекте.