Проблематика
Консалтинговые компании были подобны «сапожнику без сапог»: помогали своим клиентам оптимизировать их бизнес-процессы за счет внедрения SAP-решений, но об оптимизации собственной деятельности задумывались мало.
Каким образом, с научной и математической точек зрения, можно оптимизировать процессы?
Любой экономист вам скажет, что ключ к процветанию бизнеса в увеличении продаж, повышении производительности труда и росте качества продукта.
IT-руководители, как правило, относят справедливость данных постулатов больше к деятельности каких-нибудь заводов, выпускающим трактора или грузовики и не считают их применимыми к IT-бизнесу, полагая, что у них всё по-другому.
Это не так. Данные экономические постулаты справедливы и в случае внедрения ERP-систем в целом и SAP-систем в частности.
Рост производительности труда
Рассмотрим ситуацию: в результате проведенной оптимизации, консультант пишет постановку для АВАР-разработчика не 2-3 дня, как раньше, а за один день. АВАР-разработчик выполняет эту разработку не за 2-3 дня, а за один день. В результате, имеем рост производительности труда в 2-3 раза.
Каков экономический эффект? Возможны следующие варианты.
- На один и тот же объём работ можно выделять не 4-6 человек, а 2 человека. Затраты по зарплатам на этот объём работ снизятся в 2-3 раза, при том же уровне доходов, приходящихся на этот объем работ (рост прибыли).
- Освободившихся сотрудников можно занять другими задачами в рамках того же проекта. Таким образом, проект реализуется в 2-3 раза быстрее (рост доходов на единицу времени).
- Освободившихся сотрудников можно занять ещё одним проектом, получив дополнительный доход (рост доходов);
- Не надо нанимать дополнительных сотрудников на ещё один проект, можно обойтись имеющимися ресурсами (снижение расходов).
Рост качества
Чем более качественно выполнено и внедрено SAP-решение, тем меньше возникает ошибок при его использовании и меньше потребности в доработках.
Тем меньше консультанты и АВАР-разработчики отвлекаются, на исправление ошибок, от других задач (и тем больше производительность труда и доход компании). Тем более лояльно Заказчик относится к Подрядчику. Тем более, выигрышно компания выглядит на фоне своих конкурентов. Тем легче найти новых Заказчиков и проекты.
Развитие продаж
Если у вас не один проект, а 3 - у вас 3 источника доходов, а не 1. Даже если один крупный проект приносит столько же доходов, сколько 3 более мелких – как минимум, за счет 3-х мелких проектов мы диверсифицируем источники доходов и уменьшаем зависимость от Заказчика, уменьшаем риски от задержек с погашения дебиторской задолженностью Заказчиком. Думаю, здесь слишком очевидно, чтобы дополнительно объяснять.
В результате этих рассуждений, у нас сложилась уже более-менее ясная «картинка». У нас теперь есть понимание, что у нас всего ТРИ «святых коровы» в деле оптимизации.
Каким образом можно повысить производительность труда и качество? В этой статье мы не будем затрагивать управленческие методы типа «оптимизация штата» (т.е. сокращение сотрудников), «укрепления трудовой дисциплины», «формирование командной работы», «ужесточение контроля за выполнением задач», и т.п.
Каким образом можно увеличить продажи? Здесь мы также не будем касаться темы политических внутрикорпоративных интриг, «откатов», «распилов» и т.п. явлений.
Речь пойдёт исключительно о РАЦИОНАЛЬНЫХ ТЕХНОЛОГИЧЕСКИХ инновациях, не имеющих отношения к межличностным отношениям и способных, тем не менее, существенно повлиять на производительность труда и качество.
Обзор технологических методов улучшения показателей
В этой статье будут затронуты как очевидные общеизвестные методы и подходы, так и будут даны несколько достаточно неожиданных идей.
В этой статье мы не будем подробно освещать общеизвестные очевидные подходы, а сосредоточимся на оригинальных.
Хотя, несмотря на очевидность и общеизвестных многих вещей, редко где на проекте можно увидеть в составе команды архитектора, который бы направлял остальных участников команды и пресекал концептуальные ошибки. Часто можно увидеть рукописные АВАР-отчёты, на ручное написание которых ушло 2-3 дня, хотя их можно было сгенерировать за 1 час в SAP Query. Часто (особенно, на крупных проектах) разные консультанты поручают АВАР-разработчикам разработку дублирующих друг друга отчётов. Редко где всерьёз задумываются о том, чтобы разработать более лаконичные формы проектной документации (и, соответственно, сделать их написание менее трудоёмким) или разработать библиотеки, которые сделают АВАР-код (например, задающий параметры ALV или осуществляющий вывод в Excel), менее объёмным и трудоёмким.
Повышение производительности труда
- Стремление к повторному использованию результатов сделанной однажды работы.
- Максимальное использование стандартного инструментария для построения и генерации отчётов.
- Стандартизация, типизация АВАР-разработок и ERP-решений в целом.
- Оптимизация форм документации.
- Наличие на проекте Архитектора, владеющего «общей картиной» на проекте;
- Наличие на проекте тестировщика, который один может разгрузить нескольких консультантов;
- Конвейеризация и «экстремальное программирование».
- Использование стандартного инструментария для автоматизированного тестирования;
- Более широкое использование языка АВАР не только для реализации бизнес-логики, требующейся в рамках проектах, но и для автоматизации процесса разработки, тестирования, поиска ошибок и отладки, транспортных переносов:
- Создание парсеров и анализаторов исходного АВАР-кода;
- Создание собственного инструментария для автоматизированного поиска ошибок и расхождений между массивами данных;
- Создание собственного инструментария для укрупненного трекинга логики процессов.
- Создание собственного инструментария для уменьшения трудозатрат транспортных переносов между системами.
- Уменьшение количества рутинных операций.
Рост качества продукта
- Максимальное повторное использование выполненных ранее и хорошо отлаженных разработок, а также проверенного инструментария для генерации отчётов (см. пп. 1-2 в предыдущем разделе).
- Стандартизация, типизация АВАР-разработок и ERP-решений в целом (см. п.3 в предыдущем разделе).
- Наличие на проекте Архитектора, владеющего «общей картиной» на проекте (см. п. 5 в предыдущем разделе);
- Наличие на проекте Тестировщика, который один может разгрузить нескольких консультантов от рутинной работы по тестированию разработок (см. п. 6 в предыдущем разделе);
- Конвейеризация и «экстремальное программирование» (см. п. 7 в предыдущем разделе).
- Использование инструментария, автоматизирующего отдельные шаги процесса разработки и внедрения (см. пп. 8 и 9 в предыдущем разделе).
Как видим, некоторые методы оптимизации оказывают влияние на оба ключевых параметра: и повышают производительность труда, и одновременно повышают качество продукта.
Рост продаж
- Создание «коробочных» решений. Раз компания разработала для одного клиента удачное решение и есть основания полагать, что подобное решение нужно многим – почему бы не переработать немного это решение и не сделать на его основе «коробочное» решение, которое можно продать и другим клиентам?
- Раз компания разработала удачное коробочное решение, почему бы не перевести его на несколько языков и не попробовать продавать по всему миру, а не только в РФ и экс-СНГ? В РФ и СНГ порядка 1 тысячи клиентов SAP, по всему миру несколько десятков тысяч, шансы повторно продать тоже же самое решение в десятки раз выше.
- Раз компания имеет в штате хотя бы 5-10 сотрудников и имеет годовые обороты хотя бы 5-10 млн. рублей – зачем довольствоваться вечным «боди-шопом» и работой на субподряде? Почему бы не выйти на тендерные площадки и не поучаствовать в тендерах самостоятельно, не взять генподряд? Большинство топ-менеджеров небольших компаний считает, что «соваться в тендеры без протекции не имеет смысла, все обо всём уже давно договорились, всё давно уже поделено и распилено». Пусть даже и так, но на тендерных площадках достаточно часто попадаются и относительно небольшие тендеры (0.5-3 млн.рублей), которые попросту неинтересны крупным игрокам, но вполне могут дать стабильный доход на несколько месяцев для небольшой команды.
Другие тактические и стратегические тонкости
- «Быстро, качественно и недорого»;
- Пользовательский интерфейс;
- Операционная деятельность и ведение основных данных;
- Регламенты и формы документации;
- Фантазии Заказчика.
Более детальное описание методов и подходов
Стандартизация, типизация АВАР-разработок и ERP-решений в целом
Речь не только о пресловутых «стандартах именования объектов и переменных», которые интересны только АВАР-разработчикам (хотя и это тоже важно).
Во-первых, можно заставить АВАР-разработчиков писать отчёты по единому шаблону – с тем, чтобы любые отчёты, сделанный любыми разработчиками, были похожи «как две капли воды» в первых 100 строках АВАР-кода. Например, так:
*&---------------------------------------------------------------------*
*& Report zdemo *
*& На основе спецификации №13, постановщик Попов А., Лето 2018 *
*&---------------------------------------------------------------------*
*& Отчёт обеспечивает .... [далее копи-пэст из постановки] *
*&---------------------------------------------------------------------*
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
.
Какая выгода от такого подхода?
- Уменьшение трудоемкости для тех людей, которые будут разбираться в этом коде. Первые 100 строк АВАР-кода несут понятную и исчерпывающую информацию о структуре программы. Понятно, где что находится и «где копать». Причём, обратите внимание: информация представлена настолько доступно, что она понятна даже человеку, не являющемуся АВАР-разработчиком (например, консультанту). Она понятна даже на интуитивном уровне (особенно, если программа будет снабжена ещё и исчерпывающими комментариями).
- Уменьшение трудоемкости написания программ. Можно написать автоматический генератор, который будет автоматически генерировать «скелет» подобной программы.
- Реализацию одной программы можно отдать сразу нескольким разработчикам разного уровня квалификации одновременно. См. подробно далее в разделе «Конвейеризация».
Можно пойти дальше.
- Данные, получаемые в результате первичной выборки, всегда после выборки отображаются в виде ALV-списка всегда на экране 100. Независимо от того, какая это программа: простой отчёт, операционный отчёт (для операций с данными), транзакция ведения справочников (реестр объектов на втором экране никогда не помешает).
- Внутренняя таблица, содержащая выбранные в результате первичной выборки данные, всегда называется GTV_100, ALV-объект всегда называется ALV_100, выводится всегда в контейнер с именем ALV_100, подпрограмма настройки этого ALV всегда называется SETUP_ALV_100, а обрабатывающая события на экране – всегда USER_COMMAND_100.
- При двойном клике практически всегда происходит 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), но со следующими важными различиями:
- Нет ограничений на использование современных элементов пользовательского интерфейса;
- Процесс, в отличии от BDC, интерактивный, «онлайновый». Инструмент имеет собственный язык, способный анализировать в реальном времени реакцию тестируемой разработки, и в зависимости от ситуации изменять алгоритм тестирования.
- Инструмент работает только на SAP GUI, на клиентской машине (нет возможности запускать его в фоновом режиме). Одна это ограничение можно обойти: существует возможность, используя возможности RFC (а именно, стандартной программы rfcexec из стандартной поставки SAP GUI), SAP GUI и стандартного «Планировщика задач» MS Windows, запускать его автоматизированно, без участия человека, на выделенном компьютере.
Это даёт следующие возможности.
- Автоматическая генерация тестовых данных. Некоторые процессы сложны, и часто для ОДНОГО прогона тестируемой разработки требуется долгая кропотливая ручная работа консультанта или тестировщика в нескольких транзакциях, длительностью до получаса. Поэтому, с одной стороны, тестирование требует неоправданно много трудозатрат, а с другой стороны, получается недостаточно качественным (консультанты и тестировщики тоже живые люди). Инструмент даёт возможность генерировать тестовые данные автоматизированно, с помощью скриптов.
- Часто бывает так, что, казалось бы, полностью выполненные, отлаженные и протестированные разработки, которые давно уже никто не изменял и которым давно уже присвоили статус «Выполнено» и вообще о них забыли - неожиданно «ломаются» из-за изменений, внесённых в сопряженные разработки. Особенно это бывает неприятно, когда такая ситуация происходит на демонстрации выполненных работ Заказчику (куда все представители Подрядчика приходят в полной уверенности, что «уж теперь-то точно всё правильно работает»). Инструмент позволяет наладить постоянный автоматизированный контроль работоспособности разработок в фоновом режиме и заранее предупредить о неожиданных проблемах.
Более широкое использование языка АВАР не только для реализации бизнес-логики, требующейся в рамках проектах, но и для автоматизации процесса разработки, тестирования, поиска ошибок и отладки, транспортных переносов
Казалось бы, такая очевидная мысль, что возможности система SAP в целом и языка АВАР в частности, можно использовать не только для автоматизации бизнес-деятельности Клиента, но и своей собственной. Однако такая мысль приходит в голову, мягко говоря, не всем SAP-специалистам.
Создание парсеров и анализаторов исходного АВАР-кода.
Когда-то автор принимал участие в проекте по оптимизации давно функционирующей SAP-системы в одной крупной компании. Задачи, которые перед нами стояли: оптимизация производительности разработок, поиск уязвимостей системы (потенциально вредоносный код, недостаточность проверки полномочий, и т.п.), классификация разработок. Нас было 5 АВАР-разработчиков и 5 консультантов по разным модулям. Мы несколько месяцев усердно, скурпулезно, вручную, анализировали 2 тысячи АВАР-разработок, имевшихся в той SAP-системе.
И уже по завершению проекта поступила претензия от Заказчика: оказывается, мы совсем забыли проанализировали разработки на предмет наличия таких опасных конструкций, как прямое обновление стандартных таблиц системы. В 2 тысячах АВАР-разработок. К тому времени, команда в основном уже «разбежалась», т.к. вроде бы весь заявленный объём работ был выполнен. Остались мы вдвоём с руководителем проекта.
К счастью, я вовремя вспомнил о наличии в АВАРе оператора “READ REPORT …” . В течении дня я написал парсер, который в течении 2 минут находил все «вредоносные» программы. Затем было ещё несколько похожих задач, которые были также блестяще выполнены.
Затем пришло понимание, что ВЕСЬ тот проект мог быть выполнен силами 1-2 человек за месяц-другой (вместо 10 человек в течении полугода).
Создание собственного инструментария для автоматизированного поиска ошибок и расхождений между массивами данных.
Перед вами стоит задача: сверить два отчёта. Один эталонный, другой не очень (новые и вероятнее всего с ошибками). Одним словом, сверяете 2 массива данных между собой.
Как вы действуете? Вручную сверяете данные: пробегаетесь глазами по двум таблицам, находите различия по отдельным записям, просчитываете на калькуляторе контрольные суммы, и т.п. В лучшем случае, выгружаете в Excel и пользуетесь им для сверки двух массивов.
В результате многочасового анализа, обнаруживаете, что причина в том, что в массив «А» попали данные по заводу ХХХХ, а в массив «В» данные по этому заводу не попали. Выставляете замечание АВАР-разработчику, он в течении часа находит и вроде бы исправляет ошибку, теперь данные по заводу ХХХХ попадают в оба отчёта, но всё равно что-то не сходится, и вы начинаете сверку заново…
Не лучше ли доверить подобную работу компьютеру? Не представляет больших технических сложностей выгрузить массив данных (любую внутреннюю таблицу внутри программы) в экстракт, а затем его загрузить и проанализировать в отдельной программе.
Создание собственного инструментария для уменьшения ошибок при переносе транспортных переносов между системами.
Любому SAP-специалисту знакома ситуация, когда транспортные запросы переносятся в целевую систему с ошибками, вызванными нарушениями целостности переносимых объектов разработки. К примеру, переносимая программа использует новые таблицы (либо новые версии старых таблиц), а целевая система об этим изменениях ещё «не знает», т.к. измененные/созданные объекты разработки отсутствуют в переносимом вместе с программой запросе, и ранее ещё не переносились.
Такие ситуации чреваты потерями большого количества времени и высокими трудозатратами на подготовку и осуществление переносов. Особенно это ощутимо, когда авторы изменений (АВАР-разработчики) компании-подрядчика не имеют полномочий самостоятельно переносить сделанные изменения в целевую систему Заказчика, а вынуждены, ввиду имеющихся регламентов, обращаться к базисникам Заказчика по этим вопросам.
См. мою статью <здесь должна быть ссылка> .