Рекомендации по выбору ERP системы
From Galaktikaerp
(→Российская или западная?) |
(→Система-конструктор или закрытая система?) |
||
Line 64: | Line 64: | ||
==Система-конструктор или закрытая система?== | ==Система-конструктор или закрытая система?== | ||
- | + | Для начала определимся с терминами: | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | #'''Система-конструктор''' позволяет пользователю легко дорабатывать/изменять функционал системы. Частично или полностью такая система поставляется в исходных кодах. Представители: '''1С''', '''Парус''', '''MBS'''. | |
+ | #'''Закрытая система''' не позволяет пользователю так легко себя изменять или дорабатывать. Нельзя сказать, что закрытые системы вообще не поддаются изменению и доработке, но, по крайней мере, изменения в такие системы вносить нелегко. Представители: '''Галактика''', '''SAP'''. | ||
- | + | Преимуществом конструктора (и одновременно – ее главным недостатком) является ее гибкость. Как преимущество гибкость дает возможность оперативно исправлять ошибки системы, полноценно реализовывать требования пользователей и разрабатывать необходимый функционал. Но с ростом проекта все эти преимущества обратятся недостатками. | |
- | + | Исправление ошибок может привести к нарушению функционирования системы в совершенно неожиданных местах – ведь вы не знаете всех особенностей построения системы и не проводите интенсивного тестирования измененного кода ее. | |
- | + | Реализация большого количества требований пользователей задерживает ход работ. | |
+ | |||
+ | Разработка недостающего функционала приводит к появлению ошибок в работе системы, замедлению ее работы, остановке работ по внедрению. Наличие большого количества собственных доработок в системе повышает риски распада команды и ее поддерживаемости. | ||
'''ИТОГО''' | '''ИТОГО''' | ||
Line 87: | Line 83: | ||
Но вот существует ли такая ИДЕАЛЬНАЯ система? :) Не думаю. | Но вот существует ли такая ИДЕАЛЬНАЯ система? :) Не думаю. | ||
- | Галактика на сегодняшний день излишне закрыта. Свое ядро она править не дает ни в коем случае, оставляя возможность делать свои доработки и отчеты. Но этого в большинстве случаев достаточно. | + | К примеру, Галактика ERP на сегодняшний день излишне закрыта. Свое ядро она править не дает ни в коем случае (что есть благо), оставляя возможность делать свои доработки и отчеты. Но этого в большинстве случаев достаточно. Правда, в версии 8.1 появляются дополнительные возможности по встраиванию своих доработок в интерфейс системы и использования существующего функционала посредством WEB сервисов. |
- | 1С остается излишне открытой, хотя и не рекомендует вносить изменения в свое ядро, предлагая использовать обработки и отчеты. То есть, по уровню открытости и принципам | + | 1С остается излишне открытой, хотя поставщик и не рекомендует вносить изменения в свое ядро, предлагая использовать обработки и отчеты. То есть, по уровню открытости и принципам внедрения 1С старается приблизиться к Галактике. Что поделать, - это специфика укрупнения системы. |
==Дорогая или не очень?== | ==Дорогая или не очень?== |
Revision as of 18:07, 14 February 2007
©
Алексей <AlGo> Горбунов
Пишите
Contents |
Российская или западная?
Почему-то распространено мнение о том, что российские системы автоматизации однозначно проигрывают западным аналогам по ряду критериев - функциональность, надежность, поддерживаемость.
В корне не согласен с таким мнением.
Российский рынок ERP еще достаточно молод и на нем присутствуют как системы, имеющие многие тысячи внедрений (1С, Галактика, Парус…), так и свежеразработанные новички, развернутые на паре предприятий в пределах одного города или области. Конечно, и те и другие имеют право на существование и свою долю рынка, но под «российскими ERP системами» я буду подразумевать прежде всего представителей "большой тройки" – 1С, Галактика ERP и Парус. Немногие из малораспространенных систем дотягивают до уровня этих систем в частности и гордого звания ERP вообще.
Функциональность
Возьмем для примера КИС Галактика ERP.
Если просто перечислить все модули системы, то получится весьма внушительный список, включающий в себя производственную и складскую логистику, бухгалтерский контур, финансово-экономический блок и ряд специализированных решений (управление строительством, управление качеством, управление автотранспортом). При этом Галактику можно закупать и внедрять не только монолитным решением, но и по частям - отдельными модулями, при необходимости докупая необходимый функционал. Например, можно начать работы с закупки и внедрения модулей логистики и бухгалтерии, потом провести работы по модулю управления производственной логистике, затем - по планированию производства.
Система хорошо масштабируется, имеет в своем составе ряд средств для автоматизации территориально-распределенных компаний.
Система обладает развитыми средствами поддержки и разработки.
Какие функции западных ERP систем не реализованы в Галактике? Подскажите…
Ничья. Однозначно.
Надежность
Будем понимать под надежностью способность системы работать без значительных сбоев в течение длительного времени и на значительных объемах данных.
Любая из российских система автоматизации, имеющая сколь угодно заметную долю рынка, наверняка уже изжила наибольшую часть своих детских болячек – недоработок и банальных ошибок – без этого их развитие и продвижение было бы просто невозможно. Возможно, конечно, появление ошибок при доработке нового функционала, но от появления таких ошибок не застрахована ни западная, ни российская система.
То есть ничья.
Приспособленность к особенностям Российского законодательства
Вызывает сомнение способность западных систем корректно поддерживать особенности нашего российского законодательства. Страшны не только и не столько эти особенности, сколько скорость их появления и кардинальность корректур, вносимых ими в порядок работы. Ежегодно меняющиеся отчетные формы налоговых органов чего только стоят.
То, что крупные интеграторы разрабатывают для внедряемых ими западных систем модули учета кадров и расчета заработной платы под российскую специфику всем известно. Неизвестно – насколько качественно такая специфика реализуется и насколько полно и оперативно происходит поддержка таких уникальных решений согласно изменениям в российском законодательстве? Насколько часто и как своевременно происходит обновление отчетных форм? Как часто, насколько своевременно и корректно обновляются алгоритмы расчета ЗП, алгоритмы формирования и учета документов, другие критичные алгоритмы?
Конечно, это общая для всех систем автоматизации проблема – своевременная и полная реализация требований Российского законодательства. И является бесспорным то, что у отечественных разработчиков и специалистов технической поддержки явное преимущество в оперативности.
Явный перевес российских систем.
Имидж
Сказав, предположим, вашему западному партнеру, что у вас на предприятии работает крупная отечественная система (реально работает), вы не скажете ему ничего. Сказав, что у вас есть SAP, OEBS, MBS NAV/AX (зачастую не важно, как есть - можно оставить их в виде лицензионных сертификатов на стене кабинета генерального директора), вы приобретете значительный вес глазах зарубежных партнеров. Любая аудиторская фирма (при подготовке вашего IPO) отметит наличие у вас западной ERP системы как важный положительный момент.
При этом совершенно не важно, какая система используется вашим персоналом в своей повседневной работе.
Выбирать вам.
Кстати, Галактика поддерживает множество планов счетов - в том числе, может поддерживаться и международный стандарт GAAP.
ИТОГО
Выбирая между российской и западной системами необходимо определить для себя – что для вас важнее – получить в результате автоматизации работающую систему и автоматизированную компанию или повысить капитализацию фирмы ради, например, выпуска акций или привлечения западных инвесторов.
Если первое - выбирайте российскую систему (1С, Парус, Галактика, что-то еще). Получить работающее решение будет значительно проще. И дешевле.
Если второе - вам прямая дорога к решениям SAP, SSA ERPLN (BAAN), MBS и другим. А на складах, в производстве и в бухгалтерии у вас, скорее всего, будет работать все равно что-нибудь другое, родное.
Система-конструктор или закрытая система?
Для начала определимся с терминами:
- Система-конструктор позволяет пользователю легко дорабатывать/изменять функционал системы. Частично или полностью такая система поставляется в исходных кодах. Представители: 1С, Парус, MBS.
- Закрытая система не позволяет пользователю так легко себя изменять или дорабатывать. Нельзя сказать, что закрытые системы вообще не поддаются изменению и доработке, но, по крайней мере, изменения в такие системы вносить нелегко. Представители: Галактика, SAP.
Преимуществом конструктора (и одновременно – ее главным недостатком) является ее гибкость. Как преимущество гибкость дает возможность оперативно исправлять ошибки системы, полноценно реализовывать требования пользователей и разрабатывать необходимый функционал. Но с ростом проекта все эти преимущества обратятся недостатками.
Исправление ошибок может привести к нарушению функционирования системы в совершенно неожиданных местах – ведь вы не знаете всех особенностей построения системы и не проводите интенсивного тестирования измененного кода ее.
Реализация большого количества требований пользователей задерживает ход работ.
Разработка недостающего функционала приводит к появлению ошибок в работе системы, замедлению ее работы, остановке работ по внедрению. Наличие большого количества собственных доработок в системе повышает риски распада команды и ее поддерживаемости.
ИТОГО
Лучшей системой будет та, которая дает органично вносить необходимые изменения в свой функционал, обладает значительным готовым функционалом и не позволяет неопытным внедренцам нарушать свое ядро.
Но вот существует ли такая ИДЕАЛЬНАЯ система? :) Не думаю.
К примеру, Галактика ERP на сегодняшний день излишне закрыта. Свое ядро она править не дает ни в коем случае (что есть благо), оставляя возможность делать свои доработки и отчеты. Но этого в большинстве случаев достаточно. Правда, в версии 8.1 появляются дополнительные возможности по встраиванию своих доработок в интерфейс системы и использования существующего функционала посредством WEB сервисов.
1С остается излишне открытой, хотя поставщик и не рекомендует вносить изменения в свое ядро, предлагая использовать обработки и отчеты. То есть, по уровню открытости и принципам внедрения 1С старается приблизиться к Галактике. Что поделать, - это специфика укрупнения системы.
Дорогая или не очень?
Для начала скажу банальность - каждая компания должна подбирать систему автоматизации по своему кошельку.
Согласно длительно собираемой статистике западных компаний, общие расходы на IT нужды для компании должны укладываться в рамки 1,5-3% ее оборота.
Если расходы на IT нужды выходят за рамки данной оценки в большую сторону, то есть большие основания предполагать, что происходит переплата за софт, за услуги консультантов, за технику и т.д. Возможно, что:
- был переоценен масштаб системы автоматизации - т.е. закуплен лишний функционал;
- были выбраны слишком дорогие консультанты;
- стоимость работ по внедрению программного обеспечения вышла за планируемые рамки (возможно, в следствие срыва сроков окончания работ).
Если же IT бюджет компании меньше указанного, то возможно:
- недооценены потребности компании в функционале внедряемого программного обеспечения, что позволило закупить более дешевую систему;
- были выбраны излишне недорогие консультанты - нетребовательность консультантов к размеру оплаты своего труда зачастую означает то, что они не обладают достаточным опытом для ведения проектов необходимого уровня/масштабов - а это грозит (не обязательно, но возможно) затягиванием сроков работ и ставит под вопрос возможность успешного завершения работ вообще;
- львиная доля работ по внедрению/развитию/поддержке внедряемого программного обеспечения лежит на плечах внутреннего подразделения компании - это, в общем-то, неплохо, но кардинально повышает риск поддерживаемости системы и риск распада команды внедрения.
Следует заметить, что определить общую стоимость проекта по внедрению сложного программного обеспечения в начале или перед началом работ практически нереально. Вот несколько причин этого:
- Для начального этапа работ не закупается полный комплект необходимых лицензий. Берутся только основные модули (если это возможно), но уж точно в ограниченном количестве. В дальнейшем стоимость лицензий на програмное обеспечение может вырости многократно (в 2-3 раза). Выяснить же необходимый объем лицензий можно только в ходе опытной или промышленной эксплуатации. С другой стороны, надо заметить, что эти дополнительные выплаты заказчику наиболее понятны и прозрачны - т.е. если вместо 4 менеджеров по сбыту в компании используется 6 - значит, дополнительные 2 лицензии надо закупить. Как рабочий стол или компьютер для новых работников.
- На начальном этапе работ невозможно определить полный перечень ДОПОЛНИТЕЛЬНОГО объема работ, который необходимо будет выполнить в ходе внедрения. В том же, что такая необходимость возникнет, можно не сомневаться. Мотивировка исполнителя-консультанта достаточно проста - договор на выполнение работ по автоматизации заключается либо на объемы работ, определяемые жестко прописаным ТЗ, либо объемом стандартного функционала, имеющегося в системе. На некоторые уступки - отступление от ТЗ, доработка нестандартных отчетных форм, исполнитель/консультант может пойти, но только на некоторые и небольшие по объему. Если же заказчик хочет что-то значительное сверх договоренного объема работ, то он должен будет за это заплатить. А желание (или даже необходимость) выйти за рамки ТЗ/имеющегося функционала наверняка появится в ходе работ.
- Цена, оговариваемая продавцами системы и заказчиком в ходе предварительных переговоров, является некоторым компромисом между желанием продавцов продать, а заказчиков - купить систему. Продавцы стремяться сформировать такое финансовое предложение, которое было бы не слишком мало (хорошая система не может стоить мало), но и не слишком велико. При этом они понимают, что "войдя" в проект, заказчику будет очень тяжело из него выйти, не доведя до конца. Поэтому если в середине проекта возникнет необходимость в дополнительном финансировании проекта, клиент скорее всего, изыщет дополнительные средства для этого.
ИТОГО
Суммы, указанные в коммерческих предложениях продавцов систем автоматизации можно в большинстве случаев смело умножать на 2 или на 3 - это даст вам неплохое представление о РЕАЛЬНОЙ стоимости проекта.
Хорошим решением будет заказ оценки стоимости проекта независимому консультанту.
Оценочная стоимость проекта (включая другие расходы на ИТ нужды предприятия) должна составлять порядка 1.5-3 % оборота вашей компании.
Распространенная или нет?
Миллионы мух ошибаются ежедневно!
© Народ
Широта распространения системы не гарантирует ее применимость для автоматизации именно вашего предприятия.
Лучше ориентироваться на наличие профильных внедрений выбранной вами системы.
Наличие профильного внедрения
Наиболее важный и показательный критерий применимости системы для автоматизации вашего предприятия.
Лучшим способом выбрать систему для автоматизации предприятия является ознакомления с тем, как сделана автоматизациях на предприятиях, наиболее похожих на ваше. Более того - если на профильном предприятии работает система автоматизации, то всегда есть резон перенести опыт этого предприятия на ваше. Включая организацию бизнес-процессов, систему автоматизации, команду консультантов и поддерживающего персонала.
Доступность поддерживающего персонала
При выборе системы также важно ориентироваться на наличе персонала, готового поддерживать (а, возможно, и развивать) вашу информационную систему. Возможно, в вашем регионе легко можно найти специалиста по 1С, а по SAP'у - днем с огнем. Подумайте тогда - так ли уж для вас нужен и важен SAP?
Best-of-breed или комплексная система
По степени интегрированности корпоративной информационной системы я бы выделил три основных варианта:
- Лоскутная автоматизация
- Или классическая постсоветская автоматизация. На одном предприятии работает множество программ, которые разработаны на совершенно различных технологиях, написаны без учета необходимости в последующей интеграции между собой, разработаны многими коллективами без создания единого управления и использования единых стандартов. Качество программных продуктов также различно.
- Интеграция между отдельными програмными продуктами возможна
- на уровне данных баз данных - путем перекачки данных из формата одной системы в формат другой
- на уровне промежуточных форматов - путем выгрузки и последующей закрузки текстовых, например, файлов установленного стандарта
- на уровне ручного переноса необходимых данных
- Набор интегрированных специализированных систем
- Решение будущего? Вопрос.
- На предприятии работает множество систем, которые отвечают каждая за свой участок работы. Складом управляет лучшая система управления складом (WMS), производством - система производственного планирования и управления (MRP), инструментом оперативной работы менеджеров служит система управления отношениями с клиентами (CRM), бухгалтерские службы используют бухгалтерский пакет (трехбуквенного сокращения не знаю - буду использовать двухбуквенное - 1С) ну и так далее. В отличие от лоскутной автоматизации все системы спроектированы с учетом необходимости в интеграции между собой на основании стандартных интерфейсов и технологий.
- Технологий интеграции множество:
- CORBA
- SOA
- т.д. и т.п.
- Такое построение системы хорошо тем, что за каждый участок работы отвечает програмный продукт, который приспособлен для этого наилучшим образом. Это обеспечивает эффективность работы персонала на каждом из участков работы и полноту передаваемых между системами информации за счет использования качественных интеграционных механизмов. Доработка отдельных систем для повышения их эффективности упрощена, так как взаимодействие между ними происходит через строго определенные интерфейсы.
- Возможно, за таким построением корпоративных информационных систем будущее.
- Интегрированная система
- Все-в-одном.
- Весь необходимый функционал реализован в рамках одной системы. Вопрос интеграции данных между отдельными модулями обычно не стоит. Зачастую возникает другая проблема - как разбить такую единую <монолитную> систему на составляющие части для раздельного их внедрения с целью упрощения работ и повышения управляемости проекта.
- Обычно в таких системах функционал отдельных модулей уступает специализированным системам. Работа персонала в них также не настолько эффективна, как в специализированных решениях. Доработка таких систем для повышения эффективности работы зачастую невозможна в силу неявности связей между отдельными модулями системы или в силу ее закрытости.
Наиболее нежизнеспособное решение - по первому варианту. Это понятно и комментариев не требует.
Основной выбор в настоящее время делается между вторым и третьим вариантом.
- Стоимость решения
- Сложно сравнить решения по стоимости. Без детальной оценки конкретного проекта сложно определить, что будет дороже - внедрить монолитную систему или набор связаных специализированных систем.
- Взаимодействие с консультантами
- Если отдельные решения по второму варианту представляются различными поставщиками, то предстоит выстраивание и поддержка отношений со множеством консультантов вместо одного в случае интегрированной системы. Что, конечно, более затратно, сложно и рисковано.
- Человеческие ресурсы
- Поддержка набора интегрированных систем обычно требует значительно большего количества поддерживающего персонала. Также поддерживающий персонал должен будет обладать знаниями всех систем, используемых в работе предприятия.
- Сроки внедрения
- Думаю, что они будут больше при внедрении набора специализированных систем, ведь кроме вопросов, связаных с отдельными системами, придется решать вопросы интеграции их между собой, что само по себе займет значительное время.
- Сложность проекта
- Внедрять множество систем значительно сложнее и требует значительно большей квалификации внедряющего персонала. В ходе проекта придется учитывать особенности множества систем.
ИТОГО Возможно, лучшим балансом между внедрением интегрированной системы и набора специализированных систем, будет внедрение интегрированной системы с разработкой узкоспециализированных систем на основании данных интегрированной системы.
Поясню, что я имею в виду. На примере Галактики и необходимости в системе управлении складом.
Считается, что у Галактики сильный контур логистики, включающий в себя в том числе модули "Складской учет" и "Управление сбытом". В общем-то, это верно. Функциональности системы вполне достаточно для большинства УЧЕТНЫХ складских операций. Но, предположим, нам необходимо организовать систему управления складом со следующими возможностями и особенностями:
- Минимальное использование ручного ввода информации - повсеместное использование штрихового кодирования.
- Маркирование продукции уникальными номерами - штрих-кодами.
- Контроль приходных документов.
- Формирование отгрузки продукции по заказу клиента.
- Резервирование продукции из свободных остатков.
- Выведение продукции в свободные остатки.
- Инвентаризация склада.
- Контроль отгрузки продукции.
- Подробнее здесь.
Галактика этого делать не умеет. Надо либо внедрять специализированное решение, либо разрабатывать его самостоятельно/на заказ. Специализированная система может потребовать значительного объема доработок для реализации всех функциональных требований и возникнет необходимость ее интеграции с "большой" системой. Это приведет к увеличению времени внедрения и значительным финансовым затратам.
Разработка же под заказ такой системы может быть выполнена:
- В рамках системы Галактика
- В Галактике имеется возможность разработки собственных модулей произвольной функциональности.
- К преимуществам такого решения можно отнести сохранение монолитности системы, единообразие средств автоматизации.
- К недостаткам - слабость и ограниченность встроенного языка Галактики, возможные сложности в ходе поддержки (проблемы при переходе на новую версию) и др.
- Силами вендора
- Разработка необходимой системы заказывается вендору. Стоимость работ высока, но гарантируется высокая степень интеграции и корректности работы вновь разработанного функционала с уже имеющимся.
- Своими силами
- Стоимость работ разумна. Корректность взаимодействия вновь разработанного функционала с уже имеющимся не гарантируется и определяется опытом разработчиков.
- Вне рамок системы Галактика с использованием любой среды разработки по вашему желанию.
- К преимуществам такого решения относится прежде всего гибкость - функциональные возможности специализированной системы ничем не ограничены. Степень интеграции также высока - необходимые данные можно брать непосредственно из БД Галактики.
- К недостаткам - необходимость поддержки и обслуживания нескольких разных систем.
Итог
Суммируя все вышесказанное, можно сказать, что наиболее подходящей для вашего предприятия является система, которая:
- Имеет внедрения по вашему профилю
- Функционал наиболее соответствует вашим потребностям
- Стоимость (полная стоимость проекта) укладывается в рамки 1.5-3% от оборота вашей компании
- Специалисты по поддержке которой наиболее доступны в ваших условиях (региональных, финансовых и др.)
- Для реальной работы лучше выбирать российскую систему. В целях увеличения капитализации/улучшения имиджа - западную.
- Может быть закрытой, но обязательно должна поддерживать возможность разработки дополнительных обработок/отчетов/обработок.
- Лучше выбрать интегрированную систему с отдельной доработкой/разработкой необходимых узкомпециализированных решений.