Проблематика

Консалтинговые компании были подобны «сапожнику без сапог»: помогали своим клиентам оптимизировать их бизнес-процессы за счет внедрения SAP-решений, но об оптимизации собственной деятельности задумывались мало.

Сейчас наш мир находится в состоянии финансового кризиса, поэтому самое время подумать над вопросами оптимизации.

Каким образом, с научной и математической точек зрения, можно оптимизировать процессы?

Любой экономист вам скажет, что ключ к процветанию бизнеса в увеличении продаж, повышении производительности труда и росте качества продукта.

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

Однако, это не так. Данные экономические постулаты справедливы и в случае внедрения ERP-систем в целом и SAP-систем в частности.

Рост производительности труда

Рассмотрим ситуацию: в результате проведенной оптимизации, консультант пишет постановку для АВАР-разработчика не 2-3 дня, как раньше, а за один день. АВАР-разработчик выполняет эту разработку не за 2-3 дня, а за один день. В результате, имеем рост производительности труда в 2-3 раза.

Каков экономический эффект? Возможны следующие варианты.

1. На один и тот же объём работ можно выделять не 4-6 человек, а 2 человека. Затраты по зарплатам на этот объём работ снизятся в 2-3 раза, при том же уровне доходов, приходящихся на этот объем работ (рост прибыли).
2. Освободившихся сотрудников можно занять другими задачами в рамках того же проекта. Таким образом, проект реализуется в 2-3 раза быстрее (рост доходов на единицу времени).
3. Освободившихся сотрудников можно занять ещё одним проектом, получив дополнительный доход (рост доходов);
4. Не надо нанимать дополнительных сотрудников на ещё один проект, можно обойтись имеющимися ресурсами (снижение расходов).

Рост качества

Чем более качественно выполнено и внедрено SAP-решение, тем меньше возникает ошибок при его использовании и меньше потребности в доработках.

Тем меньше консультанты и АВАР-разработчики отвлекаются, на исправление ошибок, от других задач (и тем больше производительность труда и доход компании). Тем более лояльно Заказчик относится к Подрядчику. Тем более выигрышно компания выглядит на фоне своих конкурентов.  Тем легче найти новых Заказчиков и проекты.

Развитие продаж

Если у вас не один проект, а 3 - у вас 3 источника доходов, а не 1. Даже если один крупный проект приносит столько же доходов, сколько 3 более мелких – как минимум, за счет 3-х мелких проектов мы диверсифицируем источники доходов и уменьшаем зависимость от Заказчика, уменьшаем риски от задержек с погашения дебиторской задолженностью Заказчиком. Думаю, здесь слишком очевидно, чтобы дополнительно объяснять.

В результате этих рассуждений, у нас сложилась уже более-менее ясная «картинка». У нас теперь есть понимание, что у нас всего ТРИ «святых коровы» в деле оптимизации.

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

Каким образом можно увеличить продажи? Здесь мы также не будем касаться темы политических внутрикорпоративных интриг, «откатов», «распилов» и т.п. явлений.

Речь пойдёт исключительно о РАЦИОНАЛЬНЫХ ТЕХНОЛОГИЧЕСКИХ инновациях, не имеющих отношения к межличностным отношениям и способных, тем не менее, существенно повлиять на производительность труда и качество.

Обзор технологических методов улучшения показателей

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

В этой статье мы не будем подробно освещать общеизвестные очевидные подходы, а сосредоточимся на оригинальных.

Хотя, несмотря на очевидность и общеизвестных многих вещей, редко где на проекте можно увидеть в составе команды архитектора, который бы направлял остальных участников команды и пресекал концептуальные ошибки.  Часто можно увидеть рукописные АВАР-отчёты, на ручное написание которых ушло 2-3 дня, хотя их можно было сгенерировать за 1 час в SAP Query.  Часто (особенно, на крупных проектах) разные консультанты поручают АВАР-разработчикам разработку дублирующих друг друга отчётов. Редко где всерьёз задумываются о том, чтобы разработать более лаконичные формы проектной документации (и, соответственно, сделать их написание менее трудоёмким) или разработать библиотеки, которые сделают АВАР-код (например, задающий параметры ALV или осуществляющий вывод в Excel), менее объёмным и трудоёмким.

Повышение производительности труда

1. Стремление к повторному использованию результатов сделанной однажды работы.
2. Максимальное использование стандартного инструментария для построения и генерации отчётов.
3. Стандартизация, типизация АВАР-разработок и ERP-решений в целом.
4. Оптимизация форм документации.
5. Наличие на проекте Архитектора, владеющего «общей картиной» на проекте;
6. Наличие на проекте тестировщика, который один может разгрузить нескольких консультантов;
7. Конвейеризация и «экстремальное программирование».
8. Использование стандартного инструментария для автоматизированного тестирования;
9. Более широкое использование языка АВАР не только для реализации бизнес-логики, требующейся в рамках проектах, но и для автоматизации процесса разработки, тестирования, поиска ошибок и отладки, транспортных переносов:
   1. Создание парсеров и анализаторов исходного АВАР-кода;
   2. Создание собственного инструментария для автоматизированного поиска ошибок и расхождений между массивами данных;
   3. Создание собственного инструментария для укрупненного трекинга логики процессов.
   4. Создание собственного инструментария для уменьшения трудозатрат транспортных переносов между системами.
   5. Уменьшение количества рутинных операций.

Рост качества продукта

1. Максимальное повторное использование выполненных ранее и хорошо отлаженных разработок, а также проверенного инструментария для генерации отчётов (см. пп. 1-2 в предыдущем разделе).
2. Стандартизация, типизация АВАР-разработок и ERP-решений в целом (см. п.3 в предыдущем разделе).
3. Наличие на проекте Архитектора, владеющего «общей картиной» на проекте (см. п. 5 в предыдущем разделе);
4. Наличие на проекте Тестировщика, который один может разгрузить нескольких консультантов от рутинной работы по тестированию разработок (см. п. 6 в предыдущем разделе);
5. Конвейеризация и «экстремальное программирование» (см. п. 7 в предыдущем разделе).
6. Использование инструментария, автоматизирующего отдельные шаги процесса разработки и внедрения (см. пп. 8 и 9 в предыдущем разделе).

Как видим, некоторые методы оптимизации оказывают влияние на оба ключевых параметра: и повышают производительность труда, и одновременно повышают качество продукта.

Рост продаж

1. Создание «коробочных» решений. Раз компания разработала для одного клиента удачное решение и есть основания полагать, что подобное решение нужно многим – почему бы не переработать немного это решение и не сделать на его основе «коробочное» решение, которое можно продать и другим клиентам?
2. Раз компания разработала удачное коробочное решение, почему бы не перевести его на несколько языков и не попробовать продавать по всему миру, а не только в РФ и экс-СНГ? В РФ и СНГ порядка 1 тысячи клиентов SAP, по всему миру несколько десятков тысяч, шансы повторно продать тоже же самое решение в десятки раз выше.
3. Раз компания имеет в штате хотя бы 5-10 сотрудников и имеет годовые обороты хотя бы 5-10 млн. рублей – зачем довольствоваться вечным «боди-шопом» и работой на субподряде? Почему бы не выйти на тендерные площадки и не поучаствовать в тендерах самостоятельно, не взять генподряд? Большинство топ-менеджеров небольших компаний считает, что «соваться в тендеры без протекции не имеет смысла, все обо всём уже давно договорились, всё давно уже поделено и распилено». Пусть даже и так, но на тендерных  площадках достаточно часто попадаются и относительно небольшие тендеры (0.5-3 млн.рублей), которые попросту неинтересны крупным игрокам, но вполне могут дать стабильный доход на несколько месяцев для небольшой команды.

Другие тактические и стратегические тонкости

1. «Быстро, качественно и недорого»;
2. Пользовательский интерфейс;
3. Операционная деятельность и ведение основных данных;
4. Регламенты и формы документации;
5. Фантазии Заказчика.

Более детальное описание методов и подходов

Стандартизация, типизация АВАР-разработок и ERP-решений в целом

Речь не только о пресловутых «стандартах именования объектов и переменных», которые интересны только АВАР-разработчикам (хотя и это тоже важно).

Во-первых, можно заставить АВАР-разработчиков писать отчёты по единому шаблону – с тем, чтобы любые отчёты, сделанный любыми разработчиками, были похожи «как две капли воды» в первых 100 строках АВАР-кода. Например, так:

*&---------------------------------------------------------------------*

*& Report  zdemo                                                       *

*& На основе спецификации №13, постановщик Попов А., Лето 2015         *

*&---------------------------------------------------------------------*

*& Отчёт обеспечивает .... [далее копи-пэст из постановки]             *

*&---------------------------------------------------------------------*

 

REPORT  zdemo .

 

INCLUDE: zdemo_data     " Определение глобальных типов и переменных

       , zdemo_selscr . " Определение селекционного экрана

 

START-OF-SELECTION .

  PERFORM select_data . " Первоначальная выборка данных

 

END-OF-SELECTION .

 

  IF sy-subrc > 0 .

    MESSAGE s001(zcommon) . " Сообщение "Данных не найдено"

  ELSE.

    CALL SCREEN 100 .       " Вызов главного экрана с ALV

  ENDIF .

 

*&---------------------------------------------------------------------*

*  Каталог экранов и ключевых подпрограмм

*&---------------------------------------------------------------------*

  IF 1 = 2 .

    CALL SCREEN: 200            " Какой-то другой (вспомогательный) экран

               , 300 .          " Ещё какой-то другой (вспомогательный) экран

    PERFORM: setup_alv_100      " Настройка ALV главного экрана

           , user_command_100   " Обработка нажатий клавиш на главном экране

           , key_func1          " Функция, вызываемая на главное экране

             key_func2 .        " Другая функция, вызываемая на главное экране

  ENDIF.

*&---------------------------------------------------------------------*

 

  INCLUDE: zalv_utils           " Общие утилиты для снижения трудоёмкости

                                " работы с ALV

        ,  zoptim_utils   .     " Общие утилиты для снижения вычислительных

                                " затрат (оптимизация производительности)   

* Инклуды экранов

  INCLUDE: zdemo_s200           " Экранная логика вспомогательного экрана 200

         , zdemo_s300           " Экранная логика вспомогательного экрана 300

 Какая выгода от такого подхода?

1. Уменьшение трудоемкости для тех людей, которые будут разбираться в этом коде. Первые 100 строк АВАР-кода несут понятную и исчерпывающую информацию о структуре программы. Понятно, где что находится и «где копать». Причём, обратите внимание: информация представлена настолько доступно, что она понятна даже человеку, не являющемуся АВАР-разработчиком (например, консультанту). Она понятна даже на интуитивном уровне (особенно, если программа будет снабжена ещё и исчерпывающими комментариями).
2. Уменьшение трудоемкости написания программ. Можно написать автоматический генератор, который будет автоматически генерировать «скелет» подобной программы.
3. Реализацию одной программы можно отдать сразу нескольким разработчикам разного уровня квалификации одновременно. См. подробно далее в разделе «Конвейеризация».

Можно пойти дальше.

1. Данные, получаемые в результате первичной выборки, всегда после выборки отображаются в виде ALV-списка всегда на экране 100. Независимо от того, какая это программа: простой отчёт, операционный отчёт (для операций с данными), транзакция ведения справочников (реестр объектов на втором экране никогда не помешает).
2. Внутренняя таблица, содержащая выбранные в результате первичной выборки данные, всегда называется GTV_100, ALV-объект всегда называется ALV_100, выводится всегда в контейнер с именем ALV_100, подпрограмма настройки этого ALV всегда называется SETUP_ALV_100, а обрабатывающая события на экране – всегда USER_COMMAND_100.
3. При двойном клике практически всегда происходит drill-down в транзакцию, предоставляющую детальную информацию (если, конечно, такая транзакция вообще существует). И для того, чтобы реализовать подобную «обвязку», не требуется больше 1 одной строчки кода. 

Данные ограничения, конечно незначительно ограничивают свободу творчества (но не настолько сильно, чтобы это было кому-то принципиально). Зато дают возможность один раз реализовать и вынести в общие библиотеки (инклуды) очень значительную часть АВАР-кода, не несущую смысловой нагрузки. О вынесении которой в такие инклуды раньше не могло быть и речи.

Подведя итоги, можно примерно оценить экономический эффект. Приведённые меры стандартизации АВАР-разработок уменьшают объём КАЖДОЙ АВАР-разработки на несколько сот строк, а трудоемкость написания примерно на 1 день (на КАЖДУЮ АВАР-разработку). Редко на каком крупном проекте бывает меньше 100 разработок в реестрах разработок. Таким образом, изложенные в этом разделе незначительные, казалось бы, инновации, дают экономический эффект порядка сотни человеко-дней (или 0.5-1 млн. рублей) на каждую сотню АВАР-разработок.

Конвейеризация и «экстремальное программирование»

Как правило, в составе команды проекта работают АВАР-программисты разной квалификации. Для всех есть свои задачи: «стажёрам» дают задачи попроще, «гуру» доверяют задачи посложнее.

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

Конвейер придумал американский автопроизводитель Генри Форд примерно 100 лет назад. Суть его в том, что разные части одного автомобиля собирают поэтапно люди разных квалификаций. 

Зачем заставлять высокооплачиваемого «гуру» заставлять заниматься той частью работы, которую может выполнить и стажёр? Ну, например: описание экрана выбора, ALV-«обвязка», вывод в Excel…

Можно на первом этапе выдать задачу «стажёру», для того чтобы он выполнил простую часть работы, а затем уже передать более опытному специалисту для выполнения более сложной части работы (выборка из БД, реализация операционных процедур, и т.п.).

Тем более, что при условии стандартизации разработок (см. предыдущий пункт), это становится гораздо проще.

Кроме того, когда несколько разработчиков работают над одной задачей – они друг друга контролируют. Они эффективно находят ошибки и недочёты в частях программы, выполненной коллегой. Таким образом, они превращаются в самоорганизующуюся команду, которой не нужны внешние контролёры. Что в конечно итоге ведёт к повышению КАЧЕСТВА.

Оценим экономический эффект. Предположим, «гуру» получает за свою работу 6-7 тысяч рублей в день, а стажёр 1-1.5 тысячи. В ЛЮБОЙ АВАР-разработке примерно 2 человеко-дня занимает работа, которую может выполнить стажёр. Таким образом, экономический эффект составит от 9 до 13 тысяч рублей НА КАЖДУЮ разработку. Что составит 0.9-1.3 млн. рублей на каждую сотню разработок. Плюсуем с суммами из предыдущего раздела. Получаем сумму порядка 1.4-2 млн. рублей на каждую сотню разработок.

Использование стандартного инструментария для автоматизированного тестирования

                В любой стандартной SAP-системе есть достаточно продвинутый инструмент автоматизированного тестирования под названием eCATT. Инструмент этот незаслуженно обойдён вниманием.

Он позволяет создавать скрипты, имитирующие действия пользователя, наподобие «пакетного ввода» (BDC), но со следующими важными различиями:

1. Нет ограничений на использование современных элементов пользовательского интерфейса;
2. Процесс, в отличии от BDC, интерактивный, «онлайновый». Инструмент имеет собственный язык, способный анализировать в реальном времени реакцию тестируемой разработки, и в зависимости от ситуации изменять алгоритм тестирования.
3. Инструмент работает только на SAP GUI, на клиентской машине (нет возможности запускать его в фоновом режиме). Одна это ограничение можно обойти: существует возможность, используя возможности RFC (а именно, стандартной программы rfcexec из стандартной поставки SAP GUI), SAP GUI и стандартного «Планировщика задач» MS Windows, запускать его автоматизированно, без участия человека, на выделенном компьютере.  

                Это даёт следующие возможности.

1. Автоматическая генерация тестовых данных. Некоторые процессы сложны, и часто для ОДНОГО прогона тестируемой разработки требуется долгая кропотливая ручная работа консультанта или тестировщика в нескольких транзакциях, длительностью до получаса. Поэтому, с одной стороны, тестирование требует неоправданно много трудозатрат, а с другой стороны, получается недостаточно качественным (консультанты и тестировщики тоже живые люди). Инструмент даёт возможность генерировать тестовые данные автоматизированно, с помощью скриптов.
2. Часто бывает так, что, казалось бы, полностью выполненные, отлаженные и протестированные разработки, которые давно уже никто не изменял и которым давно уже присвоили статус «Выполнено» и вообще о них забыли - неожиданно «ломаются» из-за изменений, внесённых в сопряженные разработки. Особенно это бывает неприятно, когда такая ситуация происходит на демонстрации выполненных работ Заказчику (куда все представители Подрядчика приходят в полной уверенности, что «уж теперь-то точно всё правильно работает»). Инструмент позволяет наладить постоянный автоматизированный контроль работоспособности разработок в фоновом режиме и заранее предупредить о неожиданных проблемах.

Более широкое использование языка АВАР не только для реализации бизнес-логики, требующейся в рамках проектах, но и для автоматизации процесса разработки, тестирования, поиска ошибок и отладки, транспортных переносов

Казалось бы, такая очевидная мысль, что возможности система SAP в целом и языка АВАР в частности, можно использовать не только для автоматизации бизнес-деятельности Клиента, но и своей собственной. Однако такая мысль приходит в голову, мягко говоря, не всем SAP-специалистам.

Создание парсеров и анализаторов исходного АВАР-кода.

                Когда-то автор принимал участие в проекте по оптимизации давно функционирующей SAP-системы в одной крупной компании. Задачи, которые перед нами стояли: оптимизация производительности разработок, поиск уязвимостей системы (потенциально вредоносный код, недостаточность проверки полномочий, и т.п.), классификация разработок. Нас было 5 АВАР-разработчиков и 5 консультантов по разным модулям. Мы несколько месяцев усердно, скурпулезно, вручную, анализировали 2 тысячи АВАР-разработок, имевшихся в той SAP-системе.

И уже по завершению проекта поступила претензия от Заказчика: оказывается, мы совсем забыли проанализировали разработки на предмет наличия таких опасных конструкций, как прямое обновление стандартных таблиц системы. В 2 тысячах АВАР-разработок. К тому времени, команда в основном уже «разбежалась», т.к. вроде бы весь заявленный объём работ был выполнен. Остались мы вдвоём с руководителем проекта.

К счастью, я вовремя вспомнил о наличии в АВАРе оператора “READ REPORT …” . В течении дня я написал парсер, который в течении 2 минут находил все «вредоносные» программы. Затем было ещё несколько похожих задач, которые были также блестяще выполнены.

Затем пришло понимание, что ВЕСЬ тот проект мог быть выполнен силами 1-2 человек за месяц-другой (вместо 10 человек в течении полугода).

Создание собственного инструментария для автоматизированного поиска ошибок и расхождений между массивами данных.

Перед вами стоит задача: сверить два отчёта. Один эталонный, другой не очень (новые и вероятнее всего с ошибками). Одним словом, сверяете 2 массива данных между собой.

Как вы действуете? Вручную сверяете данные: пробегаетесь глазами по двум таблицам, находите различия по отдельным записям, просчитываете на калькуляторе контрольные суммы, и т.п. В лучшем случае, выгружаете в Excel и пользуетесь им для сверки двух массивов.

В результате многочасового анализа, обнаруживаете, что причина в том, что в массив «А» попали данные по заводу ХХХХ, а в массив «В» данные по этому заводу не попали. Выставляете замечание АВАР-разработчику, он в течении часа находит и вроде бы исправляет ошибку, теперь данные по заводу ХХХХ попадают в оба отчёта, но всё равно что-то не сходится, и вы начинаете сверку заново…

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

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

Любому SAP-специалисту знакома ситуация, когда транспортные запросы переносятся в целевую систему с ошибками, вызванными нарушениями целостности переносимых объектов разработки. К примеру, переносимая программа использует новые таблицы (либо новые версии старых таблиц), а целевая система об этим изменениях ещё «не знает», т.к. измененные/созданные объекты разработки отсутствуют в переносимом вместе с программой запросе, и ранее ещё не переносились.

Такие ситуации чреваты потерями большого количества времени и высокими трудозатратами на подготовку и осуществление переносов.         Особенно это ощутимо, когда авторы изменений (АВАР-разработчики) компании-подрядчика не имеют полномочий самостоятельно переносить сделанные изменения в целевую систему Заказчика, а вынуждены, ввиду имеющихся регламентов, обращаться к базисникам Заказчика по этим вопросам.

См. мою статью <здесь должна быть ссылка> .

Другие тактические и стратегические тонкости

«Быстро, качественно и недорого».

Существует расхожее мнение, что любой Заказчик хочет, чтобы его потребности были реализованы быстро, качественно и недорого. Но из этого списка 3-х характеристик одновременно осуществимы только 2 (либо качественно и быстро, но дорого; либо быстро и недорого, но некачественно; либо качественно и недорого, но долго).

 Мысль в том, что даже если идеал (достижение всех трёх характеристик) недостижим, это ещё не значит, что к нему не надо стремиться. Потому что другая крайность, анти-идеал (выполнить некачественно, дорого и за долгое время) достичь вполне реально. Необходимо стараться хотя бы «убегать» от этого «анти-идеала».

Пользовательский интерфейс.

Системы SAP задумывались и создавались немцами, а у них своеобразные представления о пользовательском интерфейсе. Кроме того, некоторые стандартные SAP-разработки очень стары и ведут свою историю ещё с тех времён, когда технологии пользовательского интерфейса вообще в мире были не развиты так, как сейчас. Поэтому SAP-системы известны своим кошмарным пользовательским интерфейсом. Это, безусловно, их недостаток. Однако среди некоторых SAP-специалистов распространено мнение, что такой пользовательский интерфейс - это нормально и даже хорошо и правильно. Таким подходом они создают проблемы и пользователям Заказчика, и себе.

1. Иногда руководители Заказчика всецело полагаются на мнение конечных пользователей и не хотят глубоко вникать в суть технических вопросов самостоятельно. Если конечные пользователи будут настаивать, что пользоваться разработанным вами SAP-решением НЕУДОБНО, это может создать дополнительные препятствия для сдачи работ.
2. Часто Заказчик внедряет SAP-систему взамен «самописных» заказных разработок, которые были созданы специально под нужды Заказчика. Как правило, эти разработки имеют удобный пользовательский интерфейс, который позволял справляться с большим объёмом работы силами сравнительно небольшой группы сотрудников. Если внедряемое SAP-решение существенно повысит трудоемкость проведения типовых бизнес-операций, эта небольшая группа сотрудников перестанет физически справляться с тем же объёмом работ, с которым раньше прекрасно справлялась. Следовательно, Заказчику придется расширять штат и набирать новых сотрудников – а это уже неожиданные дополнительные финансовые затраты для него, серьёзный денежный вопрос. Что также может создать серьёзные препятствия для сдачи работ.

Между тем, очень часто можно с минимальными усилиями улучшить интерфейс и существенно снизить трудоёмкость операций. Например, вместо того, чтобы «гонять» пользователя по множеству отдельных транзакций для выполнения элементарных операций, можно написать простую «обвязку», которая автоматизирует ввод данных в разных транзакциях, и таким образом скроет от пользователя часть элементарных операций, связав их в одну. Тем более, что часто это можно сделать с помощью такого удобного и простого инструмента, как «пакетный ввод» (BDC).

Операционная деятельность и ведение основных данных.

Когда-то Автор принимал участие в интереснейшем проекте по созданию «коробочного» SAP-решения для нужд государственных казначейств разных стран. У проекта был спонсор, который инвестировал приличные деньги в его реализацию. Проект предусматривал наличие множества оригинальных справочников основных данных, отсутствующих в стандартных системах SAP.

Наша команда сделала роковую ошибку, сосредоточившись, в первую очередь, на написании красивых, правильных и удобных транзакций для ведения основных данных (ОЗ лицевых счетов клиентов, ОЗ аналитических казначейских счетов, и т.п.). А написание операционных транзакций (с помощью которых можно было бы создавать документы, осуществлять проводки и т.п.) отложив на «потом».

Когда по прошествии полугода работы Инвестор потребовал показать результаты сделанной работы, наша команда не смогла предоставить ему ничего, кроме мириады красивых транзакций для ведения мириады совершенно непонятных для него справочников. Непонятных – потому что непонятно для чего предназначенных, т.к. к тому времени нами ещё не было написано ни одной операционной транзакции, с помощью которых можно было бы продемонстрировать процесс.

В результате финансирование было тут же заморожено, проект был закрыт, а команда распущена.

Мысль в том, что качественно подготовленные основные данные и правильные транзакции для их ведения – безусловно, нужны. И прекрасно, когда Заказчик понимает необходимость и важность этой работы. Однако существует риск, что работа, выполненная командой, не будет оценена по достоинству, если команда слишком увлечётся, в первую очередь, разработками для ведения ОД, забыв об операционных транзакциях. Возможно, в некоторых случаях на первом этапе лучше обойтись упрощёнными транзакциями ведения ОД, сгенерированными в SE11, для того чтобы в дальнейшем вернуться к их доработке и улучшению – а на первом этапе сосредоточиться всё-таки на реализации операционных транзакций, для того чтобы как можно скорее  обрести возможность продемонстрировать Заказчику бизнес-процесс в динамике.

Регламенты и формы документации .

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

В результате, когда наступает «экстремальная» фаза – например, когда нужно срочно дорабатывать решение и сдавать работы – об этих условностях забывают. Регламенты не выполняются. Большая часть полей в документации практически никогда не заполняется. Потому что в «боевых» действиях эти правила оказываются нежизнеспособными. В армии на реактивных гранатометах не зря рисуют стрелку с надписью «стрелять в ту сторону». Это сделано исходя из реалий боевой обстановки, в которой данный гранатомёт и будет использоваться. Если направление выстрела можно было бы узнать только из многостраничной инструкции - это будет стоить жизни многим солдатам.

Например:

1. Зачем приводить в документации список транспортных запросов по АВАР-разработке? Эту информацию можно получить прямо в системе, с помощью инструмента «Управление версиями», в более удобном и исчерпывающем виде.
2. Зачем документировать АВАР-разработки в отдельном Word-документе (или в отдельном разделе спецификации на разработку)? Не лучше ли её задокументировать прямо в АВАР-коде этой разработки (либо в разделе «Документация»), а в спецификации дать только название одной «корневой» АВАР-разработки, в которой находится документация по всем объектам разработки в рамках данного решения?

1. Зачем делить систему разработки на два манданта? В одном из которых можно только программировать, а в другом надо вести настройки. Это вносит совершенно бессмысленное неудобство в работу. Бессмысленное – потом что все объекты разработки манданто-независимые. Изменения, сделанные в одном манданте, тут же отразятся и в другом, таким образом деление на манданты всё равно ни от чего не защищает и не приносит в работу ничего, кроме неудобства и лишних трудозатрат.
2. Понятно, когда переносы в продуктивную систему делаются только после акцепта руководителем или иным ответственным лицом. Но зачем вводить утверждения и при переносе в тестовую систему? Тестовая система – наименее ценный ресурс в системном ландшафте. Её ценность даже ниже, чем ценность системы разработки. Потому что тестовая система может быть восстановлена в любой момент и сколько угодно раз путём копирования продуктивной системы.  
3. Зачем требовать от программистов обязательно сопровождать Z-справочники текстовыми таблицами? Понятно, когда хотя бы в теории предусматривается использование данного решения интернациональными командами пользователей, говорящих на разных языках. Зачем это делать, когда такая вероятность отсутствует даже теоретически и к тому же Заказчик не выдвигал требований мультиязычности?

Фантазии пользователей.

                Мысль в том, что иногда не надо давать пользователям Заказчика «включать фантазию». Конечные пользователи, как правило, не являются IT-специалистами, и их представления о пользовательском интерфейсе и других нюансах могут быть неверными. Зато такими специалистами являются (или должны являться) консультанты и АВАР-разработчики. По крайней мере, на первом этапе они лучше пользователей знают (или должны знать), что нужно этим пользователям. Иногда лучше сразу сделать грамотное красивое решение «по своему разумению», «как надо», с удобным пользовательским интерфейсом, основываясь на своём удачном опыте предыдущих проектов. Есть вероятность, что такое решение сразу понравится пользователям и они не станут «включать фантазию», результатом работы которой могут стать труднореализуемые пожелания в виде «кнопочек с перламутровым отливом» и т.п..

А в реальности часто можно увидеть консультантов, которые целиком полагаются на представления пользователей и даже не пытаются предложить что-то своё.