Меню

Варварство специализма

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

 

Специалист подобен флюсу: полнота его одностороння.

(Козьма Прутков)

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

Уровень профессиональной компетенции специалистов – консультантов по внедрению ограничивается рамками узкой специализации. Консультанты вынуждены умещаться, сосредотачиваться, и даже замыкаться на всё более тесном пространстве мысли. Специализация вытесняет в них целостное восприятие бизнес - модели (логической схемы бизнеса). От специалиста требуется удовлетворительное знание работы «его» модуля программного обеспечения, что легко сымитировать, а проверить трудно (!). В каждый модуль при его создании вендоры закладывают алгоритмы одной, а то и нескольких современных методологий управления бизнесом. Однако у редкого консультанта хватает времени и мотивации для изучения принципов этих методологий и методов их внедрения. Если хотите в этом убедится, спросите любого консультанта: какая методология управления инкорпорирована в «его» модуль?

Как следствие, специалист не склонен напрягать свой интеллект для постижения работы ERP системы в рамках всей бизнес – модели. И в результате, если что он знает назубок, то это «свой клочок мироздания» в сложной логике настройки внедряемого программного обеспечения. В рамках управления всей логической схемой бизнеса его можно назвать «сведущим невеждой» (варваром).

 «Вертикальное вторжение варваров»

Общий прогресс цивилизации порождает ускоренный рост проблем, встающих перед бизнесом. И если в «далёкие» времена люди делились на сведущих и невежественных, то теперь всех специалистов по внедрению ERP системы (будь то менеджеры проекта, программисты

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев8

Комментарий от  

Олег Точенюк

  |  30 декабря 2011, 13:47

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

Комментарий от  

Олег Чирва

  |  30 декабря 2011, 13:52

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

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

Комментарий от  

Рафаиль Салихов

  |  30 декабря 2011, 14:52

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

5 баллов :)
)))))
"бюджетненько"

Комментарий от  

Александр Дублин

  |  30 декабря 2011, 19:28

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

Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?

Комментарий от  

Олег Точенюк

  |  31 декабря 2011, 16:49

Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?

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

Комментарий от  

Олег Точенюк

  |  31 декабря 2011, 16:50

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

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

Комментарий от  

Олег Чирва

  |  03 января 2012, 12:00

Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?

А как же народная мудрость? - "в своем глазу бревна не видно"! Стоит ли требовать полный перечень проблем от Заказчика?
Конечно, они знают ради чего запускают Проект (должны знать). Но все ж, рассчитывать на полный перечень проблем не стоит, да и в любом случае, перечень может и должен быть расширен совместными усилиями Заказчика и команды внедрения - ведь кроме не заметных изнутри проблем еще существует целый набор различных траблов, которые непосредственно проявляются при интеграции всех процессов в единую систему.
 
А по "бюджетненько" - специально взял в кавычки, поскольку, не сильно верю, что проекты внедряемые слабой командой (в т.ч. и с перегруженными разными задачами специалистами) выходят действительно бюджетными.
 
Проект СО - частности, но появление там такого архитектора, как Олег - немного повышает шансы проекта на успех!

Комментарий от  

Александр Дублин

  |  03 января 2012, 12:16

А как же народная мудрость? - "в своем глазу бревна не видно"! Стоит ли требовать полный перечень проблем от Заказчика?
Конечно, они знают ради чего запускают Проект (должны знать). Но все ж, рассчитывать на полный перечень проблем не стоит, да и в любом случае, перечень может и должен быть расширен совместными усилиями Заказчика и команды внедрения - ведь кроме не заметных изнутри проблем еще существует целый набор различных траблов, которые непосредственно проявляются при интеграции всех процессов в единую систему.
 
А по "бюджетненько" - специально взял в кавычки, поскольку, не сильно верю, что проекты внедряемые слабой командой (в т.ч. и с перегруженными разными задачами специалистами) выходят действительно бюджетными.
 
Проект СО - частности, но появление там такого архитектора, как Олег - немного повышает шансы проекта на успех!

В посте речь идет не о полном перечне проблем Заказчика, а  о целевых проблемах, которые определяют (должны!) целесообразность внедрения и заявленные результаты проекта.
Наличие бизнес-аналитика (архитектора) позволяет сформулировать проблемы и подходы к их решению (совместно с Клиентом).
Как Вы верно заметили, проекты по "сбыче мечт" всегда  успешены, так как их результат - работающее программное обеспечение, а не решение проблем бизнеса компании Заказчика.