Некоторые причины снижения эффективности проектов по автоматизации бизнес-процессов на базе ПО SAP

3582
5

Наибольшая из всех безнравственностей — это браться за дело, которое не умеешь делать.

Н.Бонапарт

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

В этой статье описаны размышления о том, от каких  моментов зависят время и “гладкость” пути, который проходит компания в проекте по внедрению системы, а также какие подводные камни встречаются на этом пути; почему компании, идущие по этому “тоннелю” не всегда “выходят к свету”, не получают результат, соответствующий их исходным ожиданиям.

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

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

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

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

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

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

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.

Функциональная область: Информационные технологии / IT, Basis, ABAP
Ролевое назначение: Руководитель / Manager
Комментарии:

Андрей Белобродский (Рейтинг: 1054) 13:38, 01 октября 2013

Пользователи не хотят участвовать в проектировании системы, не хотят знать учет и формировать TЗ.
Пользователи хотят запустить файл setup.exe и иметь интуитивно понятный интерфейс как у apple.
23:47, 01 октября 2013

Олег Точенюк (Рейтинг: 10169)

Ну это у вас задача внедрять, а у них задачи формировать ТЗ и участвовать в проектировании системы нет, они когда на работу шли, вряд ли им говорили, что мы вас берем кладовщиком, но кроме этого вы еще будете участвовать в проектировании системы и написании ТЗ,  конечно же, в свободное от основной работы время, денег мы вам при этом больше платить не будем, вы уже должны быть счастливы только от того, что участвуете в проектировании системы и повышаете свой рыночный уровень знаний.
 
Ну где-то наверное так, у вас берут на работу, как я понимаю. Если так, то понимаю вашу обиду на этих недалеких, или я бы даже сказал - близких, вам пользователей.
17:34, 03 октября 2013

Дмитрий Дворников (Рейтинг: 384)

Ну, если реальные заказчики ЕРП (акционеры и руководители компании) готовы рисковать бюджетами таких проектов, они не будут мотивировать персонал для активного участия в проектных работах... Но лучше, как говорится, один день потерять, потом за 5 минут долететь... - некоторая мотивация участников обернется экономией в разных областях и процессах.
Что же касается "интуитивно понятного интерфейса" apple - посадите за Mac человека который ни разу не видел MacOS. Увидите, что интуитивность интерфейса вдруг куда-то испарится... Чтобы что-то узнать, нужно в любом случае потратить время и усилия и с пользователями нужно грамотно работать; если говорить заезженными фразами "управлять их ожиданиями". Для этого в крупных проектах у заказчиков создаются команды бизнес-экспертов, полностью вовлекаемых в проект.
20:41, 03 октября 2013

Олег Точенюк (Рейтинг: 10169)

Согласен! Как говорил один мой хороший знакомый, интуитивно понятный интерфейс в этом мире существует только одни - сиська, родился и уже знаешь как использовать, все остальное в этом мире приходиться изучать.

Олег Шкуренков (Рейтинг: 512) 16:43, 30 октября 2013

С описываемыми проблемами сталкиваются на всех проектах: не только с ПО SAP, и не только в IT. Этапы анализа целей проекта, выявления проблем стейхолдеров, их требований и ожиданий часто не производиться, или производиться только экспресс-анализ при подготовке ТКП.
Типичная команда компании заказных решений состоит из Руководителя проекта, Архитектора, Аналитика (системного и бизнес-аналитика), Разработчиков, Тестировщиков, Технических писателей. В команде внедрения SAP зачастую несколько ролей распределены на одних и тех же членов команды. Очевидно, что консультант не может одинаково качественно провести анализ потребностей и ожиданий, собрать и проанализировать требования и ограничения, выявить и устранить противоречия, провести разработки и настройки системы, затем протестировать их и подготовить документацию.
Складывается впечатление, что на типовых проектах по внедрению SAP отсутствует системный аналитик, или сотрудник, обладающий необходимыми компетенциями. Большая часть вопросов должна сниматься именно на этапе анализа, что бы не создавать систему, не удовлетворяющую ни заказчика (по стоимости, срокам, ROI и др. бизнес показателям), ни пользователей (по функционалу, релевантности, удобству и пр.).
Если в среде SAP нет своего Вигерса и Леффингуэлла, то нужно не бояться перенимать опыт из смежных областей разработки ПО.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»