Отступление 1. Без неё ERP на предприятии не внедрить

Мы прошли уже три этапа внедрения ERP. Запустили процессы движения материалов, ДСЕ, контролируем и уточняем НСИ, НЗП, ДПЦ и загрузку оборудования. Обычно, на куда более ранних стадиях проекта возникает вопрос по теме, о которой пойдет речь в этой статье - система отчетности! Без неё, действительно невозможно внедрить ERP систему.

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

Предыдущая статья: НЗП и ДПЦ при внедрении ERP на предприятии.

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

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

• мнение руководителей служб, где идет внедрение – а оно чаще всего негативное, потому что радикальные перемены всегда встречают сопротивление;
• мнение приближенных к руководителям «знатоков» о том, чего они никогда не делали, но точно знают как надо и это наверняка не так, как делают не они – а таких рядом с любым руководством очень, очень много.

Каковы цели?

• Выбрать среду разработки отчетов.
• Минимизировать затраты предприятия на внедрение системы отчетности.
• Минимизировать затраты предприятия на разработку каждого отдельно взятого отчета.

Что имеем?

Мне пока не встречалась ERP система, которая бы имела:

• большой набор готовых сложных отчетов;
• хорошую эргономику отчетов;
• широкие возможности по разработке отчетов;
• удовлетворительную динамику совершенствования системы отчетности в соответствие с прогрессом;
• простой и удобный интерфейс разработки отчетов.

Для любой маленькой системы это звучало бы как приговор, однако в системах класса ERP ценятся системность и целостность большого комплекса задач. Развитие и сопровождение таких больших комплексов съедает сотни человеко-лет разработчиков и отчетность при разработке стоит далеко не на первом месте по важности и приоритетности. Поэтому надо просто смириться с мыслью, что к ERP вам скорее всего будет нужна внешняя система отчетности.

Что делаем?

Выбрать среду разработки отчетов.

Чтобы понять саму суть и необходимость постановки такой задачи давайте вернемся немного назад к внедрению материального учета. Запущено в промышленную эксплуатацию движение МКИ по складу NNN. Как мы это можем увидеть?



Картинка показывает насколько число заинтересованных в чтении информации, превышает число пользователей, создающих её.

Кроме того, из самой картинки видно насколько разный уровень специалистов предприятия желает иметь доступ к информации NNN объекта или процесса ERP системы.

ВАЖНО. В результате успешного внедрения ERP число пользователей, имеющих доступ на чтение, будет значительно превышать число пользователей, которые вводят информацию в систему.

ВАЖНО. На начальных этапах внедрения число пользователей, запрашивающих доступ на чтение, будет расти значительно быстрее, чем число пользователей, запрашивающих доступ на ввод информации.

ВАЖНО. Практически ни один готовый отчет из ERP не будет решать задачи, которые будут запрашивать руководители и специалисты служб предприятия.

Осознавая всё вышеперечисленное необходимо уже на раннем этапе внедрения ERP разработать технические требования (техническое задание) на систему отчетности для вашего предприятия. На основе этого технического задания начать выбор системы для внедрения.

ВАЖНО. Поскольку на рынке не существует, да и не может существовать, системы с готовым набором отчетов на все случаи жизни, то подбирать необходимо среду разработки отчетов.

Техническое задание.

Важная часть любой задачи, которая должна присутствовать при выборе или создании любой мало-мальски серьезной системы. Для того, чтобы не придумывать велосипеда с вводной частью, я воспользуюсь очень хорошим материалом Александра Байкина «Стандарты и шаблоны для ТЗ на разработку ПО»

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

Макет - набор четких формулировок с требованиями к системе, разбитыми по соответствующими разделами. Чем макет, на начальном этапе, лучше готового ТЗ:

1. при заключении договора, компания партнер наверняка предложит вам свой формат ТЗ;
2. при выборе системы вы не раз и не два уточните требования относительно начального варианта.

Этого достаточно, чтобы разработчик ТЗ сказал – «я не хочу переписывать один и тот же документ много раз в местах, которые являются лишь пояснениями, но не меняют сути».

Так вот макетом ТЗ, по сути, и является только то, что надо обязательно прочитать, чтобы понять, что требуется. Все примеры, пояснения, расшифровки, оглавления, сокращения и т.д. оставьте для официального принятия документа.

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

Желательно составить макет ТЗ в двух вариантах:

• минимальные требования;
• оптимальные требования.

Требования максимум нежелательны, поскольку:

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

Минимальные требования, как правило, отражают ту функциональность, без которой реализация выбираемой системы на предприятии лишается всякого смысла. Такие требования позволяют вам более четко:

• сформулировать цели и задачи внедрения системы;
• оценить масштабы потенциального использования;
• принять наиболее востребованный набор функций и возможностей.

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

Оптимальный уровень требований является наиболее предпочтительной моделью для макета технического задания под выбор системы. Он требует дополнительно к минимальным требованиям:

• тщательного анализа применимости системы;
• более пристального взгляда на перспективы развития выбираемой системы на предприятии;
• анализа всех должностных уровней потенциальных пользователей системы для выработки требований по эргономике, форматам обмена и представления;
• анализа возможностей системы по самостоятельной доработке.

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

Выбор

К счастью существует всего три варианта выбора такой среды:

1. Использовать только среду разработки отчетов, поставляемую вместе с ERP.
2. Приобрести генератор отчетов и/или BI систему (часто слышу такой вариант – генератор отчетов + ограниченный объем лицензий BI только для высшего руководства).
3. Писать собственную среду разработки отчетов.

Выбор внутренней среды разработки ERP для разработки отчетности.

Плюсы:

• нулевые затраты, поскольку среда идет в составе уже приобретенной ERP и лицензии разработчиков уже приобретены;
• нет необходимости переобучения или дообучения разработчиков, поскольку со средой ERP они уже плотно работают в рамках проекта внедрения ERP;
• единая СУБД.

Минусы:

• плохая эргономика – это бич крупных систем;
• развитие среды разработчиком ERP практически отсутствует;
• использование данных из нескольких источников даже с одной СУБД реализовано крайне слабо;
• очень ограничены возможности разработки сложных, зависимых (вложенных) отчетов;
• отсутствует возможность самостоятельной доработки среды;
• применение ограничено количеством приобретенных лицензий;

Выбор генератора отчетов.

Плюсы:

• отличная эргономика;
• вывод во множество форматов для презентации, печати или пересылки;
• множество самых распространенных и одновременно несколько источников данных;
• есть генераторы, заточенные под конкретные ERP;
• возможность создавать сложные, зависимые (вложенные) отчеты.

Минусы:

• высокий уровень затрат на приобретение;
• высокий уровень затрат на содержание;
• обучение разработчиков и пользователей;
• отсутствует возможность самостоятельной доработки среды;
• чаще всего применение ограничено количеством приобретенных лицензий;

Выбор BI инструментария.



Плюсы:

• отличная эргономика;
• возможность создавать очень сложные отчеты;
• вывод во множество форматов для презентации, печати или пересылки;
• применительно к работе с ERP - один источник данных;
• возможности инструментов уже настолько широки, что вопрос развития (совершенствования) представления данных не актуален.

Минусы:

• очень высокий уровень затрат на приобретение;
• высокий уровень затрат на адаптацию среды к работе с вашими данными;
• высокий уровень затрат на содержание;
• очень серьезное обучение разработчиков;
• повышение затрат на заработную плату сотрудникам ИТ, задействованным в разработке, содержании и обслуживании BI на предприятии;
• большие финансовые и временные затраты на создание хранилища данных;
• большие затраты на приобретение железа под хранилище данных;
• большие трудозатраты на поддержание в актуальном и синхронном состоянии хранилища данных при интенсивном внедрении ERP;
• применение ограничено количеством приобретенных лицензий.

Самостоятельная разработка среды разработки отчетности.

Плюсы:

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

Минусы:

• повышение затрат на заработную плату сотрудникам ИТ, задействованным в разработке, содержании и обслуживании среды разработки отчетов;
• затраты на серьезное обучение разработчиков самой среды;
• большие временные затраты на разработку среды;
• вероятные затраты на лицензируемое ПО применяемое для разработки среды или являющееся компонентом разрабатываемой среды;
• не самый высокий уровень эргономики.

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

Моя рекомендация – самостоятельная разработка системы отчетности. Исходя из личного опыта разработки и применения системы отчетности, разработанной ИТ отделом предприятия, могу отметить:

• на наиболее тяжелых стадиях внедрения и на стадиях бурного «роста» системы, мы бы точно не получили дополнительного финансирования на систему отчетности, на её техническую поддержку или на приобретение дополнительных лицензий на ERP для предоставления отчетности пользователям;
• повышенные требования к эргономике в отчетах у пользователей начали появляться только через год после запуска задач в эксплуатацию;
• интеграция с ERP, доработки, развитие, оптимизация полностью в ваших руках;
• экономия для предприятия от непокупки дополнительных лицензий ERP или генератора отчетов, или BI исчисляется десятками миллионов рублей в год.

Помимо того, что этой разработкой вы сэкономите предприятию сотни миллионов рублей, при грамотном подходе и развитии - система могла бы стать отдельным перспективным гражданским бизнесом предприятия. Это на заметку предприятиям ВПК, которые исторически имеют большие ИТ коллективы.

Результат подпункта.

1. Составлен макет ТЗ.
2. Выбрана среда разработки отчетов.
3. оставлено ТЗ.
4. Подписан договор на внедрение или создана группа по разработке среды разработки отчетности.

Минимизировать затраты предприятия на внедрение системы отчетности.



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

На этапе внедрения необходимо проработать план развертывания системы таким образом, чтобы:

• число лицензий на каждом этапе было минимально необходимым;
• число пользователей, которым нужна отчетная информация соответствовало заявкам от подразделений.

Существует несколько вариантов реализации подобной стратегии без нарушения лицензионного соглашения с компанией поставщиком:

• конкуретные лицензии с разделением доступа между пользователями по времени;
• именные или конкурентные лицензии с назначением ответственных за формирование отчетности + инструмент предоставления доступа к готовому отчету всем заинтересованным пользователям;
• именные лицензии для автоматического запуска формирования отчетов по расписанию + инструмент предоставления доступа к готовому отчету всем заинтересованным пользователям.

Неудобно и далеко от online?

Да, это правда!

Но, если у Вас покупная система отчетности, то это куда лучше, чем скажем $8000 за именную лицензию для руководителя, который должен иметь возможность посмотреть отчет в любую минуту, но фактически смотрит его только раз в месяц 29-го числа и… крайне редко в непредсказуемое время.

Предлагаемые решения могут и должны идти симбиозом с online доступом к отчетам с критической для бизнеса информацией, если Вы такую действительно обнаружите.

Принцип определения эффективности именного доступа на просмотр информации таков:
(экономия + прибыль от использования информации > стоимости формирования и получения этой информации в заданный период).

ВАЖНО. Это лишь принцип, а не готовая формула, поскольку её невозможно посчитать в абсолютных цифрах из-за огромного числа косвенных, вспомогательных и сопутствующих факторов влияющих на значения с обеих сторон неравенства. В тоже время, применение этой формулировки для ответов на вопросы – «а что это даст?», «для кого это наиболее эффективно?» может дать существенную экономию на отсутствии необходимости решения ряда задач и создания ряда отчетов на определенном этапе развития компании и реализации системы.

Возвращаясь к руководителю выше – отчеты, которые дает ему система под именной лицензией, должны окупить затраты «$8000 + ($8000 * 0,20) * количество лет» экономией или прибылью от верных и своевременных решений на основе этой информации.

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

В качестве инструмента предоставления доступа к готовым отчетам всем заинтересованным пользователям, присутствующего в моделях оптимизации затрат, могут выступать:

• СУБД;
• файловые сервера;
• электронная почта с настроенными группами;
• облака частные, публичные, корпоративные;
• внутренний раздел корпоративного сайта предприятия или отдельный корпоративный web сервер;
• корпоративная система электронного документооборота.

Важно. Рекомендации этого подраздела применимы в случае приобретения систем разработки отчетов. Система собственной разработки позволяет устанавливать отчеты, выдающих информацию в режиме online, любому числу пользователей и имеет по большей части только ресурсные ограничения сервера.

Результат подпункта.

• Разработана модель внедрения с минимальными затратами.
• Внедрены сопутствующие сервисы обмена информацией.
• Выпущен организационный документ с правилами и принципами предоставления доступа к отчетам.
• Внедрена среда разработки отчетов.
• Созданы первые необходимые отчеты.
• Предоставлены доступы пользователям в соответствие с выбранной моделью предоставления доступов и распространения отчетов.

Минимизировать затраты предприятия на разработку каждого отдельного отчета.



Задача сокращения затрат на разработку отчетов должна стоять внутри ИТ службы как один из ключевых показателей деятельности подразделения. Какие бы методы не применялись, сокращение может происходить за счет двух основных направлений:

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

В тоже время, методы сокращения затрат на разработку зависят от доступа (возможностей) ИТ подразделения  к доработке непосредственно среды разработки отчетов:

• культура проектирования и программирования;
• документирование;
• база готовых шаблонов и FAQ'и;
• полностью готовые к применению объекты – модули, скрипты, визуальные и безинтерфейсные компоненты, DLL, API, пакеты;
• выделенная команда сопровождения и развития среды разработки.

Культура проектирования и программирования.

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

• краткое описание реализуемых целей и задач;
• краткое описание достигаемых целей или получаемого результата;
• ответственного или автора;
• краткое описание получаемого результата задачи или метода;
• краткое описание исходной информации или параметров – входящих и возвращаемых;
• краткое описание используемых терминов или переменных;
• историю изменений: даты внесения изменений, ответственного или автора, причины изменений, краткое описание получаемого результата.

Во многих компаниях, где существуют такие правила, их соблюдение носит рекомендательный характер, однако есть компании с куда более жесткой, и на мой взгляд, более правильной политикой – неоднократное (более трех раз) несоблюдение правил ведет к автоматическому увольнению из компании, не обращая внимания на чин и звания.

Почему и зачем так жестко? Дело в том, что основными целями соблюдения правил является:

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

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

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

Документирование.



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

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

Чем понятнее, доступнее, конструктивнее создана документация, тем лучше и быстрее новый сотрудник станет полноценным работником для компании.

Когда вы впервые открываете, ну скажем, MS Word - вы видите множество панелей управления с кучей кнопок. Назначение многих из этих кнопок интуитивно непонятны даже бывалому сёрферу по Интернету (а на предприятия всё чаще стали приходить именно И-сёрферы). Для того, чтобы человек не оказался в ситуации информационного вакуума, существует документация или help по системе – что, в общем, практически одной и тоже в разных формах.

Практически это же необходимо создать для пользователей отчетов на предприятии.
Разработчикам отчетов, помимо предыдущего документа необходима ещё документация, инструкция с примерами по созданию простого отчета, а также правила по культуре проектирования или программирования.

Выделенная команда сопровождения и развития среды разработки.

Надо – и ещё раз, это надо сделать. Независимо от того, приобретете вы среду для разработки отчетов или сделаете её самостоятельно, в ИТ подразделении должна быть выделенная команда, которая будет отвечать за:

• изучение всех возможностей инструмента или его развитие и совершенствование;
• выработку правил проектирования или их систематизацию;
• создание наиболее сложных примеров для обучения остальных сотрудников;
• разработку базы готовых шаблонов и FAQ'ов, модулей, скриптов, визуальных и безинтерфейсных компонентов, DLL, API, пакетов;
• общение с технической поддержкой по системе;
• разработку, актуализацию документации по самой системе и для ИТ разработчиков, и для пользователей отчетов.

Минимизация затрат на отчет

Если от команды разработчиков отчетов ИТ подразделения требовать:

• соблюдения правил культуры проектирования и программирования;
• использования документации;
• применения готовых решений, предложенных командой сопровождения и развития среды разработки отчетов;

при этом этой команде будет обеспечен постоянный доступ к:

• хранилищу готовых решений;
• базе шаблонов;
• описанию готовых решений, шаблонов и истории их изменений;
• документации;
• другим разработкам и истории их изменений;

затраты на разработку отчетов становятся контролируемой и управляемой величиной.

Результат подпункта.

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

Кирпичик в фундамент.



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

Если на данной стадии вы не введете системы показателей для самой ИТ службы, то впоследствии её специалисты, не прочувствовавшие на своей шкуре трудностей, с которыми столкнуться подразделения при введении показателей, могут начать принимать эффективные решения с точки зрения системы, но далеко не самые оптимальные для предприятия.

Следующая статья: Финансы - справочники. Внедряем ERP на промышленном предприятий - шаг 4.

Автор: Андрей Лабутин