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

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

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

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

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

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

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