`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Трудности комплексной автоматизации

Статья опубликована в №22 (688) от 23 июня

0 
 

Мы часто говорим об успехах. Как хорошо, когда все получается! А если не получается или получается не то или не вовремя? Почему так происходит в самой, казалось бы, точной отрасли – в информационных технологиях? Почему мы бываем недовольны и разочарованы ERP-системами? Попробую поделиться своим скромным мнением о комплексной автоматизации. Это не все, а лишь яркие, запомнившиеся моменты.

Неопределенность цели

Начинается все с цели. Каким образом формулируется цель проекта комплексной автоматизации? Обычно так: нужно автоматизировать все! Это первая серьезная ошибка. Автоматизировать все – не цель, ведь сделать так с ограниченными бюджетом и сроками нельзя. Это мечта, которая заранее делает цель проекта недостижимой. Только формулировка пусть сложных, но рациональных целей может привести к успешному завершению проекта. Данная деятельность по своей природе неповторима, она направлена на получение некоего результата, создание конкретного продукта или услуги при заданных ресурсах и сроках, а также требованиях к качеству и допустимому уровню риска. Целью не может считаться автоматизация бухгалтерского учета с описанием функциональности ПО на 300 страниц без установленных четко сроков и бюджета. Потому как в подобном случае, идеально автоматизировав бухгалтерский учет, владелец бизнеса может израсходовать такую сумму денег, которую смог бы платить целому штату бухгалтеров в течение 20 лет. Это тот эффект, которого ждали? Наверное, нет.

Следует задаться вопросом: что мы хотим получить в результате? Учетное решение, процессную систему или нечто большее? ПО может позволять учитывать, но не обеспечивать процесс. Такая детализация цели влияет в особенности на стоимость. А многие задачи, которые хотелось бы видеть будущим получателям результатов проекта, не решены до сих пор и являются исследовательскими с неопределенными сроками реализации. Возьмем, к примеру, внедрение полноценной процессной модели предприятия. В одних компаниях такая цель достижима, в других – нет, потому что организация может функционировать не процессно. Если нет регламентации процессов, как их можно автоматизировать? Попытка сделать это с большой долей вероятности приведет к провалу. Где гарантия, что только что записанное вами каким-либо внутренним приказом без вашего ведома не будет аннулировано?

Отсутствие системного подхода

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

Замена вместо преемственности

Часто при внедрении ПО ERP-класса не уделяют должного внимания старой системе. Отчасти это делается с целью сокращения трудозатрат по проекту, отчасти – из-за твердой веры в новое решение. Но ведь раньше предприятие как-то работало, пусть была неэффективная лоскутная автоматизация, но система функционировала! И в ходе эксплуатации в течение ряда лет она, вероятно, позволила накопить определенный объем знаний и опыта, отличающийся по глубине от предлагаемых новой системой лучших практик.

Функциональная структура предприятия

Грубо говоря, выделяют три основные структуры управления предприятием: функциональную, матричную и проектную. Самую сложную задачу выполняет руководитель проектов в функциональной организации, поскольку сотрудники предприятия данной формы чаще всего не имеют навыков и мотивации участия во внедрении. Менеджеру приходится прилагать значительные усилия для направления всех ресурсов такой компании на проект. Цель сотрудника функциональной организации – обеспечение операционной деятельности компании. Конфликт целей приводит к конфликтам личностей. Особенно тяжелая ситуация возникает при внешнем проекте: как правило, менеджмент не может понять необходимость в проекте и дать полномочия его руководителю на управление ресурсами предприятия. Обычно говорят: «Вы нам объясните, как оно работает, а дальше мы сами...». Но ответственность за некорректные или несбалансированные действия пользователей все равно несет внешний эксперт, поскольку он должен был проконтролировать процесс.

Хаос в данных

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

Подмена понятий

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

Проект управляется строго по PMBOK 2004

Стандарт не является алгоритмом, он не панацея от всех бед, а всего-навсего best practice – попытка систематизации того, что было на других проектах, причем не разовая, а постоянный процесс накопления и классификации подобных знаний и опыта. Управляющий, опирающийся только на стандарт, будет хорошим исполнителем, но не хорошим менеджером. Любой проект интересен сам по себе, он уникален, здесь всегда будет неопределенность, которую нельзя терять из виду вплоть до окончания работ. Не стоит надеяться только на прописные истины даже в самых простых проектах.

Следует обратить внимание на новый стандарт PMBOK 2008. Одной из его основных идей является концепция прототипирования – создания промежуточного результата, который можно посмотреть и, что самое главное, – подвергнуть критике. Если в стандарте 2004 г. мы имели только набор инструментов, обобщенно описывающих различные процессы управления проектами, то в новой редакции PMBOK проявилась конечная цель любого проекта – прототип. Я считаю, что по сравнению со старым вариантом это большой шаг вперед, позволяющий существенно уменьшить проектные риски.

Неадекватное планирование

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

Нехватка нагрузочного тестирования

После приобретения ERP-системы и проведения базовых или полных курсов обучения персонала нередко игнорируется стандартный в цикле разработки ПО этап – нагрузочное тестирование. Оно особенно важно при больших потоках информации в системе. Непонимание этого факта может привести к целой цепочке негативных последствий.

Резюме

Работа CIO по количеству учитываемых параметров и динамике развития предметных областей относится к самым сложным профессиям в мире. Как заметил Александр Кардаков, председатель наблюдательного совета «Октава Капитал», в одной из своих записей, доступных на ресурсе Best CIO 2009, чтобы быть востребованным, ИТ-лидер должен четко понимать цели бизнеса. Скажу даже больше: для того чтобы комплексно и системно автоматизировать деятельность компании, руководитель проекта или ИТ-управляющий обязан понимать всю картину функционирования предприятия в десятки раз глубже реального руководителя. Задачи автоматизации, которые ставятся сейчас, служат уже далеко не автоматизации учета или даже процессов. Современные руководители переносят на систему функции управления! Свои функции. В динамично развивающейся фирме ERP-система принимает решений намного больше, чем ее глава... Может, и не по их значимости, но по количеству – так точно. А управляет созданием системы обычный человек. И я глубоко убежден, что именно от правильного выбора этого сотрудника и зависит успех любого проекта автоматизации.

ko-online.com.ua/best-cio/blogs

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT