Главная | О нас | Наша барахолка | Мероприятия | Публикации | Юмор | Полезные ссылки | Автосоветы | Компас Киев | Аудио КВ | Книги | Кино | Форум |

Cтраничка Экскурсовода



Привет Всем!

Хочу рассказать Вам
о карьере ИТ-специалиста.
Вы найдете мои публикации
и переведенные статьи
из иностранных источников,
о том, как сделать правильно
карьеру ИТ-специалиста.
Надеюсь, что информация,
полученная здесь, Вам
очень пригодиться!

Связаться со мной:
maxsch@ukr.net


Наше Личное

Страничка Доктора
Страничка Хрюшкина
Страничка Экскурсовода
Страничка Штурмана
Golden-WEB
Fedka@Records




Пробки на Яндекс.Картах

Интересное на сайте

Электротехнологии



Компас Киева



Юморная страничка



Книги на сайте



Кино на сайте



Десять причин, по которым ERP-проекты заходят в тупик, и не только ERP

Переводная статья

Список провалишихся SAP-внедрений в Германии достаточно длинный. «Это хуже, чем Брекзит, Трамп и торговая война», пишет газета «Франкфуртер Альгемайне». Неважно, какое программное обеспечение использовалось – это не главная причина краха проектов. Значительно большую роль играют нижеприведенные факторы.

1. Людские ресурсы.

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

Далее, в этом контексте важной является прозрачность проекта для руководителей подразделений. Они должны знать, для чего и на какой период нужно отдать сотрудника, будет ли сотрудник занят в проекте 100% своего времени или меньше.

Например, сначала 80% на этапе планирования, затем 50% на этапе разработки, и 100% на этапе тестирования и ввода в эксплуатацию. Этот пункт должен быть чётко оговорен, поскольку часто возникают трения между руководителями проекта и подразделениями предприятия.

2. Не хватает навыков ведения проектов.

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

Кто не находился в подобной ситуации? Здесь надо всегда оставаться честным, а для сложных вопросов под рукой должен быть профильный специалист.

3. Вместо того, чтобы придерживаться стандартов, пользователь выдвигает свои хотелки.

Это классика среди причин затягивания сроков и последующих проблем. Что делать, когда юзер привык к привычномуму режиму работы и требует его копирования в новой системе? Классический аргумент – эта процедура критично важна для предпрития, без неё никуда и изменение несёт такие риски, с которыми раньше никто не сталкивался.

Другая крайность: если цепляться за стандарты и игнорировать пожелание юзеров, то результатом может быть сопротивление вплоть до сознательного саботажа. Здесь очень нужны чуткость, лидерские качества и навыки управления изменениями. Руководитель пользователя должен чётко понимать свою ответственность за то, чтобы внятно объяснить своему сотруднику, насколько это важно и какие выгоды тот получит в конечном итоге.

4. Недостаточное внимание тестированию.

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

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

5. Обучение.

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

Очевидно, насколько важно всё спланировать заранее – прежде всего для того, чтобы руководство понимало, что во время тренингов оно не может распоряжаться своими сотрудниками. Вывод: Тот, кто заранее предусмотрел эти затраты, может спать спокойно.

6. Нормативно-справочная информация (НСИ).

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

Если до сих пор нет ответственного за данные, то этим должны будут заняться ключевые пользователи в ущерб своим собственным задачам в проекте. Отсюда однозначно следует, что данные должны быть подготовлены заранее, желательно до начала внедрения. Соответствующие роли и зоны ответственности должны быть чётко регламентированы. Это неблагодарная, тяжёлая работа, на которую трудно найти подходящих людей, однако для успеха проекта это необходимо.

7. Стратегия внедрения.

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

8. Приоритеты проекта.

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

Подобные паузы приводят к тому, что все участники должны снова вникать в тему, что не очень-то и мотивирует. Топ-менеджмент должен ясно понимать, что это имеет серьёзные последствия для успеха проекта. Ресурсы не должны отвлекаться на другие проекты! В этой ситуации от руководства требуется быть хорошими политиками.

9. Процесс изменений.

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

10. Стадия завершения проекта.

Последний по списку, но не по важности пункт. К сожалению, часто проблемы возникают при передаче всех функций в подразделения и подписании акта представителями Заказчика. Только официальный документ ясно утверждает, что проект завершен, в каком состоянии результаты переданы пользователям, какие вопросы остаются пока открытыми и кто этим должен заниматься. Это уже не техзадание, а инструкции для соответствующих подразделений организации. После этого руководитель проекта и его подчинённые могут считать свою работу выполненной и вернуться на свои рабочие места либо получить новое задание.

Заключение.

Эти десять пунктов чётко показывают, что внедрение ERP – не столько ИТ-проект, сколько перестройка работы целой организации. Проблемы возникают не из-за программного обеспечения как такового, а из-за вышеперечисленных пробелов в организации проекта.

Я желаю вам принять во внимание эти десять пунктов и сделать их фундаментом успешных внедрений.

Оригинал статьи читать здесь >>>>>








Главная | Мероприятия | Публикации | Юмор | Аудио КВ | Книги | Кино | Форум

(C) Киевский Вариант, 2006