Рекомендации по выбору ERP системы

From Galaktikaerp

Revision as of 10:05, 29 December 2006

Оглавление

Российская или западная?

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

В корне не согласен с таким мнением.

Давайте подробнее.

Функциональность

Понятно, что если назвать ERP системой программу, которая имеет пять-десять региональных внедрений, может решать задачи логистики и <слегка> бухгалтерии, модуль "Производство" которой находится в "опытной" эксплуатации на паре предприятий невеликого масштаба, тогда да, ЭТА "Система ERP" БУДЕТ проигрывать западным системам по функциональности.

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

Ничья. Однозначно.

Надежность

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

То есть ничья.

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

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

Кстати, для Галактики это проблема - своевременно обновлять/поставлять отчетные формы. Хотя разработчики и специалисты технической поддержки стараются исправить ситуацию.

Явный перевес российских систем.

Имидж

А вот тут выигрыш у западных систем.

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

Выбирать вам.

Кстати, Галактика поддерживает множество планов счетов - в том числе, может поддерживаться и международный стандарт GAAP.

ИТОГО

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

Если первое - склонитесь к российской системе (Галактика, 1С, Парус, что_то_еще). Получить работающее решение будет значительно проще. И дешевле.

Если второе - вам прямая дорога к SAP'у, BAAN'у (не помню, как он ныне называется...), MBS'у и другим западным гигантам. А на складах, в производстве и в бухгалтерии у вас, скорее всего, будет работь все равно что-нибудь другое, родное.

Система-конструктор или закрытая система?

Сперва определимся с терминами:

1. Система-конструктор позволяет пользователю легко дорабатывать/изменять функционал системы.

   Ярчайшим представителем таких систем является 1С (являлась до версии 7.7 включительно?)

   Парус тоже дает возможность дорабатывать себя

   MBS при закупке необходимых лицензий тоже превращается в некоторое подобие большого 1С 'а

2. Закрытая система не позволяет пользователю так легко себя изменять/дорабатывать. Нельзя сказать, что закрытые системы вообще не поддаются изменению и доработке, но, по крайней мере, изменения в такие системы вносить нелегко.

   Галактика - закрытая система, обладающая возможностью использовать наработки пользователей в виде обработок отчетов.

   SAP я бы тоже отнес в эту категорию.

Преимуществом конструктора (и одновременно - ее недостатком) является ее гибкость. Имея в руках такую систему очень трудно удержаться от соблазна доработать ее согласно ВСЕМ требованиям пользователей. В разумных пределах доработки необходимы и важны, но при значительных их объемах приводят к резкому возрастанию рисков неподдерживаемости системы и разрушения команды.

В масштабах среднего и крупного внедрения чрезвычайно не рекомендуется вносить изменения в ядро системы. Даже в систему-конструктор.

Можно лишь создавать дополнительные обработки и отчеты, которые не затрагивают основы логики системы.

Пусть изменения ядра остануться работой для централизованной службы поддержки/разработки вашей системы.

ИТОГ

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

Но вот существует ли такая ИДЕАЛЬНАЯ система? :) Не думаю.

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

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

Дорогая или не очень?

Для начала скажу банальность - каждая компания должна подбирать систему автоматизации по своему кошельку.

Согласно длительно собираемой статистике западных компаний, общие расходы на IT нужды для компании должны укладываться в рамки 1,5-3% ее оборота.

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

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

Если же IT бюджет компании меньше указанного, то возможно:

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

Следует заметить, что определить общую стоимость проекта по внедрению сложного программного обеспечения в начале или перед началом работ практически нереально. Вот несколько причин этого:

• Для начального этапа работ не закупается полный комплект необходимых лицензий. Берутся только основные модули (если это возможно), но уж точно в ограниченном количестве. В дальнейшем стоимость лицензий на програмное обеспечение может вырости многократно (в 2-3 раза). Выяснить же необходимый объем лицензий можно только в ходе опытной или промышленной эксплуатации. С другой стороны, надо заметить, что эти дополнительные выплаты заказчику наиболее понятны и прозрачны - т.е. если вместо 4 менеджеров по сбыту в компании используется 6 - значит, дополнительные 2 лицензии надо закупить. Как рабочий стол или компьютер для новых работников.
• На начальном этапе работ невозможно определить полный перечень ДОПОЛНИТЕЛЬНОГО объема работ, который необходимо будет выполнить в ходе внедрения. В том же, что такая необходимость возникнет, можно не сомневаться. Мотивировка исполнителя-консультанта достаточно проста - договор на выполнение работ по автоматизации заключается либо на объемы работ, определяемые жестко прописаным ТЗ, либо объемом стандартного функционала, имеющегося в системе. На некоторые уступки - отступление от ТЗ, доработка нестандартных отчетных форм, исполнитель/консультант может пойти, но только на некоторые и небольшие по объему. Если же заказчик хочет что-то значительное сверх договоренного объема работ, то он должен будет за это заплатить. А желание (или даже необходимость) выйти за рамки ТЗ/имеющегося функционала наверняка появится в ходе работ.
• Цена, оговариваемая продавцами системы и заказчиком в ходе предварительных переговоров, является некоторым компромисом между желанием продавцов продать, а заказчиков - купить систему. Продавцы стремяться сформировать такое финансовое предложение, которое было бы не слишком мало (хорошая система не может стоить мало), но и не слишком велико. При этом они понимают, что "войдя" в проект, заказчику будет очень тяжело из него выйти, не доведя до конца. Поэтому если в середине проекта возникнет необходимость в дополнительном финансировании проекта, клиент скорее всего, изыщет дополнительные средства для этого.

ИТОГ

Суммы, указанные в коммерческих предложениях продавцов систем автоматизации можно в большинстве случаев смело умножать на 2 или на 3 - это даст вам неплохое представление о РЕАЛЬНОЙ стоимости проекта.

Хорошим решением будет заказ оценки стоимости проекта независимому консультанту.

Оценочная стоимость проекта (включая другие расходы на ИТ нужды предприятия) должна составлять порядка 1.5-3 % оборота вашей компании.

Распространенная или нет?

Широта распространения системы не гарантирует ее применимость для автоматизации именно вашего предприятия.

Лучше ориентироваться на наличие профильных внедрений выбранной вами системы.

Наличие профильного внедрения

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

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

Доступность поддерживающего персонала

При выборе системы также важно ориентироваться на наличе персонала, готового поддерживать (а, возможно, и развивать) вашу информационную систему. Возможно, в вашем регионе легко можно найти специалиста по 1С, а по SAP'у - днем с огнем. Подумайте тогда - так ли уж для вас нужен и важен SAP?

Best-of-breed или комплексная система

По степени интегрированности корпоративной информационной системы я бы выделил три основных варианта:

1. Лоскутная автоматизация

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

   Интеграция между отдельными програмными продуктами возможна

   • на уровне данных баз данных - путем перекачки данных из формата одной системы в формат другой
   • на уровне промежуточных форматов - путем выгрузки и последующей закрузки текстовых, например, файлов установленного стандарта
   • на уровне ручного переноса необходимых данных

2. Набор интегрированных специализированных систем

   Решение будущего? Вопрос.

   На предприятии работает множество систем, которые отвечают каждая за свой участок работы. Складом управляет лучшая система управления складом (WMS), производством - система производственного планирования и управления (MRP), инструментом оперативной работы менеджеров служит система управления отношениями с клиентами (CRM), бухгалтерские службы используют бухгалтерский пакет (трехбуквенного сокращения не знаю - буду использовать двухбуквенное - 1С) ну и так далее. В отличие от лоскутной автоматизации все системы спроектированы с учетом необходимости в интеграции между собой на основании стандартных интерфейсов и технологий.

   Технологий интеграции множество:

   • CORBA
   • SOA
   • т.д. и т.п.

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

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

3. Интегрированная система

   Все-в-одном.

   Весь необходимый функционал реализован в рамках одной системы. Вопрос интеграции данных между отдельными модулями обычно не стоит. Зачастую возникает другая проблема - как разбить такую единую <монолитную> систему на составляющие части для раздельного их внедрения с целью упрощения работ и повышения управляемости проекта.

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

Наиболее нежизнеспособное решение - по первому варианту. Это понятно и комментариев не требует.

Основной выбор в настоящее время делается между вторым и третьим вариантом.

• Стоимость решения

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

• Взаимодействие с консультантами

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

• Человеческие ресурсы

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

• Сроки внедрения

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

• Сложность проекта

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

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

Поясню, что я имею в виду. На примере Галактики и необходимости в системе управлении складом.

Считается, что у Галактики сильный контур логистики, включающий в себя в том числе модули "Складской учет" и "Управление сбытом". В общем-то, это верно. Функциональности системы вполне достаточно для большинства УЧЕТНЫХ складских операций. Но, предположим, нам необходимо организовать систему управления складом со следующими возможностями и особенностями:

• Минимальное использование ручного ввода информации - повсеместное использование штрихового кодирования.
• Маркирование продукции уникальными номерами - штрих-кодами.
• Контроль приходных документов.
• Формирование отгрузки продукции по заказу клиента.
• Резервирование продукции из свободных остатков.
• Выведение продукции в свободные остатки.
• Инвентаризация склада.
• Контроль отгрузки продукции.
• Подробнее здесь.

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

Разработка же под заказ такой системы может быть выполнена:

1. В рамках системы Галактика

   В Галактике имеется возможность разработки собственных модулей произвольной функциональности.

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

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

   1. Силами вендора

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

   2. Своими силами

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

2. Вне рамок системы Галактика с использованием любой среды разработки по вашему желанию.

   К преимуществам такого решения относится прежде всего гибкость - функциональные возможности специализированной системы ничем не ограничены. Степень интеграции также высока - необходимые данные можно брать непосредственно из БД Галактики.

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

Итог

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

1. Имеет внедрения по вашему профилю
2. Функционал наиболее соответствует вашим потребностям
3. Стоимость (полная стоимость проекта) укладывается в рамки 1.5-3% от оборота вашей компании
4. Специалисты по поддержке которой наиболее доступны в ваших условиях (региональных, финансовых и др.)
5. Для реальной работы лучше выбирать российскую систему. В целях увеличения капитализации/улучшения имиджа - западную.
6. Может быть закрытой, но обязательно должна поддерживать возможность разработки дополнительных обработок/отчетов/обработок.
7. Лучше выбрать интегрированную систему с отдельной доработкой/разработкой необходимых узкомпециализированных решений.