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

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

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

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

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

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

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

Для чего нужны архитекторы: 8 комментариев

  1. veps

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

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

  2. VirVit Автор записи

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

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

  3. metha

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

  4. Calm

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

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

  5. VirVit Автор записи

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

  6. metha

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

  7. VanoIvanov

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

  8. VanoIvanov

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

    ВнедряЙ!

Добавить комментарий