Варварство специализма
Растёт число и сложность структурных (функциональных) компонент внедряемых ERP систем. Вендоры из лучших побуждений непрерывно расширяют возможности системы, а внедрнецы по любому поводу предпочитают «сочинение» дополнительного программного кода использованию стандартной (но неведомой их консультантам!) функциональности. Однако чем более функциональна информационная система (ERP система), встраиваемая в процесс управления, тем взаимодействие с ней сложнее и «запутанней» и растёт неопределённость реакции всей системы управления на локальное возмущение.
Специалист подобен флюсу: полнота его одностороння.
(Козьма Прутков)
Растёт число и сложность структурных (функциональных) компонент внедряемых ERP систем. Вендоры из лучших побуждений непрерывно расширяют возможности системы, а внедрнецы по любому поводу предпочитают «сочинение» дополнительного программного кода использованию стандартной (но неведомой их консультантам!) функциональности. Однако чем более функциональна информационная система (ERP система), встраиваемая в процесс управления, тем взаимодействие с ней сложнее и «запутанней» и растёт неопределённость реакции всей системы управления на локальное возмущение.
Уровень профессиональной компетенции специалистов – консультантов по внедрению ограничивается рамками узкой специализации. Консультанты вынуждены умещаться, сосредотачиваться, и даже замыкаться на всё более тесном пространстве мысли. Специализация вытесняет в них целостное восприятие бизнес - модели (логической схемы бизнеса). От специалиста требуется удовлетворительное знание работы «его» модуля программного обеспечения, что легко сымитировать, а проверить трудно (!). В каждый модуль при его создании вендоры закладывают алгоритмы одной, а то и нескольких современных методологий управления бизнесом. Однако у редкого консультанта хватает времени и мотивации для изучения принципов этих методологий и методов их внедрения. Если хотите в этом убедится, спросите любого консультанта: какая методология управления инкорпорирована в «его» модуль?
Как следствие, специалист не склонен напрягать свой интеллект для постижения работы ERP системы в рамках всей бизнес – модели. И в результате, если что он знает назубок, то это «свой клочок мироздания» в сложной логике настройки внедряемого программного обеспечения. В рамках управления всей логической схемой бизнеса его можно назвать «сведущим невеждой» (варваром).
«Вертикальное вторжение варваров»
Общий прогресс цивилизации порождает ускоренный рост проблем, встающих перед бизнесом. И если в «далёкие» времена люди делились на сведущих и невежественных, то теперь всех специалистов по внедрению ERP системы (будь то менеджеры проекта, программисты
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 8
Комментарий от
Олег Точенюк
| 30 декабря 2011, 13:47
Комментарий от
Олег Чирва
| 30 декабря 2011, 13:52
Олег Точенюк 30 декабря 2011, 13:47
Ну что-то мне кажется для этих целей и существует на проекте должность BSA, типа архитектора решения, который должен видеть в целом всю функциональность всех модулей и как они коррелируют с физическими бизнес процессами компании.
Намного чаще встречаешь ситуацию обратную, когда состав консультантов представляет собой разрозненный по направлениям коллектив. А ответственность за принятие взвешенных решений ставят на руководителя проекта. Часто, в довесок к одному из направлений, которые он непосредственно курирует.
В итоге - "бюджетненько"!
Комментарий от
Рафаиль Салихов
| 30 декабря 2011, 14:52
Олег Чирва 30 декабря 2011, 13:52
Идеально верно! Но, на каждом ли проекте выделяется архитектор решений?
Намного чаще встречаешь ситуацию обратную, когда состав консультантов представляет собой разрозненный по направлениям коллектив. А ответственность за принятие взвешенных решений ставят на руководителя проекта. Часто, в довесок к одному из направлений, которые он непосредственно курирует.
В итоге - "бюджетненько"!
)))))
"бюджетненько"
Комментарий от
Александр Дублин
| 30 декабря 2011, 19:28
Олег Точенюк 30 декабря 2011, 13:47
Ну что-то мне кажется для этих целей и существует на проекте должность BSA, типа архитектора решения, который должен видеть в целом всю функциональность всех модулей и как они коррелируют с физическими бизнес процессами компании.
Комментарий от
Олег Точенюк
| 31 декабря 2011, 16:49
Александр Дублин 30 декабря 2011, 19:28
Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?
Комментарий от
Олег Точенюк
| 31 декабря 2011, 16:50
Олег Чирва 30 декабря 2011, 13:52
Идеально верно! Но, на каждом ли проекте выделяется архитектор решений?
Намного чаще встречаешь ситуацию обратную, когда состав консультантов представляет собой разрозненный по направлениям коллектив. А ответственность за принятие взвешенных решений ставят на руководителя проекта. Часто, в довесок к одному из направлений, которые он непосредственно курирует.
В итоге - "бюджетненько"!
Комментарий от
Олег Чирва
| 03 января 2012, 12:00
Александр Дублин 30 декабря 2011, 19:28
Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?
Конечно, они знают ради чего запускают Проект (должны знать). Но все ж, рассчитывать на полный перечень проблем не стоит, да и в любом случае, перечень может и должен быть расширен совместными усилиями Заказчика и команды внедрения - ведь кроме не заметных изнутри проблем еще существует целый набор различных траблов, которые непосредственно проявляются при интеграции всех процессов в единую систему.
А по "бюджетненько" - специально взял в кавычки, поскольку, не сильно верю, что проекты внедряемые слабой командой (в т.ч. и с перегруженными разными задачами специалистами) выходят действительно бюджетными.
Проект СО - частности, но появление там такого архитектора, как Олег - немного повышает шансы проекта на успех!
Комментарий от
Александр Дублин
| 03 января 2012, 12:16
Олег Чирва 03 января 2012, 12:00
А как же народная мудрость? - "в своем глазу бревна не видно"! Стоит ли требовать полный перечень проблем от Заказчика?
Конечно, они знают ради чего запускают Проект (должны знать). Но все ж, рассчитывать на полный перечень проблем не стоит, да и в любом случае, перечень может и должен быть расширен совместными усилиями Заказчика и команды внедрения - ведь кроме не заметных изнутри проблем еще существует целый набор различных траблов, которые непосредственно проявляются при интеграции всех процессов в единую систему.
А по "бюджетненько" - специально взял в кавычки, поскольку, не сильно верю, что проекты внедряемые слабой командой (в т.ч. и с перегруженными разными задачами специалистами) выходят действительно бюджетными.
Проект СО - частности, но появление там такого архитектора, как Олег - немного повышает шансы проекта на успех!
Наличие бизнес-аналитика (архитектора) позволяет сформулировать проблемы и подходы к их решению (совместно с Клиентом).
Как Вы верно заметили, проекты по "сбыче мечт" всегда успешены, так как их результат - работающее программное обеспечение, а не решение проблем бизнеса компании Заказчика.