Для чего нужен архитектор SAP

Для чего нужен архитектор SAP

VirVit 8 комментариев
Заметки на полях Разное

Знаете ли вы хотя бы одного консультанта, который знает весь САП? Или половину? Я не знаю. Система настолько объемна и велика, что сами САПеры далеко не всегда знают, что творится в своем огороде. И это нормально, нельзя все это помнить. Консультанты обычно владеют только своим кусочком модуля, где им комфортно. По моим наблюдениям, это приводит к тому, что и задачи решаются исходя из своих “привычных” знаний.

Приведу простой пример. Сегодня я столкнулся с задачей, которая с точки зрения стандарта достаточно простая. Есть правила, функции в оценке времени, механизмы в виде PTMW и инфотипов, которые позволяют решать достаточно большой круг задач с помощью одной настройки. По тем или иным причинам задача была решена с помощью самописных решений. Проходит время, появляются новые требования, и этот нюанс всплывает наружу. Возможны два варианта развития событий. Либо переделать все обратно на стандартные решения, либо продолжить этот путь. Переделать – значит есть вероятность появления ошибок. Да и сама по себе схема оценки времени не очень гибка к переменным алгоритмам, зависимым от даты (нужно делать свои правила и в них вставлять проверки на текущее число). Зачастую приходится именно доделывать, следовать уже сложившейся практике и руководствоваться принципом “работает – не трогай”.

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

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

Зачастую, с развитием бизнеса и системы, первые вспоминают, что нужно переходить на современные метрики и просят реализовать стоимость функции в HR. Например, сколько стоит вся бухгалтерия в компании? И как же это посчитать? МВЗ были закодированы в другой плоскости, разделы/подразделы отражают географическую структуру, а структура должностей и вовсе не ведется. Это снова возвращает нас к необходимости доделывать или переделывать изначально “правильное и красивое решение”. Именно из-за этой частной проблемы я стал задумываться о том, что систему надо бы внедрять не от хотелок частного специалиста бизнеса или руководителя среднего звена, а именно “сверху”. Управляют, на мой взгляд, там, “наверху”, а все остальные только организуют реализацию управленческого “хочу”. Поэтому я бы спросил руководителя, что ему нужно сегодня и, возможно, захочется завтра.

В настоящий момент я пытаюсь сформировать и оформить свое видение реализации проектов по внедрению ERP систем. Уже есть определенные идеи в этом направлении. Возможно во второй книге это материализуется 🙂

8 комментариев

veps

Январь 24, 2013 в 3:24 дп

>Возможны два варианта развития событий.
прям таки два 🙂
(+)
реализовать новое решение.
отказаться от новых требований, как не имеющих никакой концептуальной новизны.
чем не варианты???

филиалов стало больше 100, почему не изменили число на строку ❓ стало бы AA, например.

 

VirVit

Январь 24, 2013 в 5:25 дп

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

А про филиалы все просто – куча написанных интерфесов считывала именно два символа как цифровой код со всеми вытекающими.

 

metha

Январь 24, 2013 в 8:43 дп

Ха!! Вит, чего удивляться то?! это называется ОПА МОГЛА СТАЙЛ, ОП-ОП :mrgreen:

 

Calm

Январь 24, 2013 в 12:36 пп

>>а именно «сверху»

Те сверху, кто это понимает – так и делают.
А те из тех кто сверху не понимает – не будет делать никогда. В худшем для себе случае перестанут быть сверху, но делать не будет всё равно.

 

VirVit

Январь 24, 2013 в 6:17 пп

Ром, я не удивляюсь 🙂 Ищу способ избежать этого в будущем, так как и сам могу допускать такие ошибки. Все мы люди – человеки 🙂

 

metha

Январь 25, 2013 в 9:06 пп

Ты знаешь, лично для себя понял только одно 🙂 еще когда на Никеле тогда с тобой работали ;-), нет одинаковых проектов, и таскать одни и те же толмуты концептуальных проектов ни в коем случае нельзя, надо пользоваться общей концепцией и здравым смыслом, тогда и с заказчиком будешь общаться всегда на 100% понимая друг друга. Ведь зачастую бывает как: приходит конс, знает только свою нишу и начинает убеждать заказчика, что только так как знает конс работает SAP и заказчику надо работать так же, забыв про свои обязанности и функции в компании, не говоря уже о проекте :-)), это нонсенс и такой подход вызывает только отторжение заказчика…

 

VanoIvanov

Март 5, 2013 в 10:13 пп

Приятно читать блог местами.
>>ОПА МОГЛА СТАЙЛ, ОП-ОП
GangmanStyle
>>здравым смыслом
тоже верно

 

VanoIvanov

Март 5, 2013 в 10:19 пп

Приятно читать блог местами.
>>ОПА МОГЛА СТАЙЛ, ОП-ОП
GangmanStyle
>>здравым смыслом
тоже верно

ВнедряЙ!

 

Вы должны быть авторизованы, чтобы оставить комментарий.