Несколько слов об оценке функциональности ERP- систем

[Михаил Ковалев]

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

Конечно, существуют детально разработанные методики сравнения ERP-систем. Однако можно использовать как первое приближение и простые “грубые” методы, которые, тем не менее, позволяют сразу сделать оценку по критерию “функциональность”.

Можно предложить рассмотреть в качестве системы координат следующие измерения:

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

продолжительность разработки системы (Помните известную фразу из кинофильма “Мертвый сезон” – девять женщин на первом месяце беременности не смогут родить ребенка? Требуется время, чтобы те или иные решения были выкристаллизованы.)

квалификация тех людей, которые взяли на себя ответственность за создания системы (Фактически речь может идти об оценке “качества” системы: качество идей, которые закладывались при разработке, качество продукта)

Понятно, что эти параметры не претендуют на полноту, тем не менее давайте попробуем сделать некоторые оценки. Еще раз, это только оценки и не более того.
Отечественные системы существуют на рынке около 5-10 лет. Обычно в качестве оценки количества человек, которые занимаются разработкой (постановка задачи, кодирование, тестирование) можно взять значение 20 . Таким образом, получаем оценку снизу трудозатрат – 100-200 человеколет.
Что касается системы АХАРТА, то сама система существует около 3 лет ( плюс ее прородитель Concord – не менее 5 лет), таким образом, период создания AXAPTA – около 8 лет. Что касается людей, которые, занимаются развитием функциональности, то по экспертной оценке, их не менее 200-300 человек по всему миру, Следовательно, оценка по трудозатратам никак не менее 600 человеколет.

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


М.Ковалев

[Михаил Андреев]

Вспомнился анекдот:
К капитану дальнего плавания подходит его друг и просит принять на работу своего знакомого на должность боцмана.
Капитан интересуется, что тот умеет. Друг сообщает, что точно не знает, но этот человек провел в море 20 лет. На что капитан заявляет : "Вот там в углу стоит мой сундук, который провел в море 30 лет, а толку?"

А если серьезно, то трудозатраты не всегда говорят о функциональности. Более того, результат внедрения от программы практически не зависит (ну, сейчас накинутся ).
Можно и 1С поставить на металлургическом комбинате, и внедрения SAP R/3 завалить в коммерческой палатке на рынке. Все зависит от команды внедрения, какие специалисты подобрались и как сработались друг с другом. А добиться качественной и быстрой работы команды очень сложно (даже более простые функции в команде не так-то просто выполнять - вспомним футбольные матчи ).

[Михаил Ковалев]

Михаил, Вы безусловно правы, ведь речь идет об оценке "потенциальных" функциональных возможностей систем.
Я абсолютно согласен c утверждением, что внедрить можно все (помните знаменитый русский метод из анекдота как "накормить кота горчицей")
Искусство (???) менеджера проекта и заключается в том, чтобы выбрать оптимальный набор функциональных возможностей из доступных (пока не будем уточнять критерии оптимальности) чтобы реализовать обещанное клиенту. В принципе, мы подходим к вопросу о методологии внедрения

М.Ковалев

[Pavel]

Привет, участникам,

С удовольствием перешел бы на отечественную систему, однако таковых (ERP класса) просто не существует.
Ситуацию с критериями оценки можно упростить (если продолжить мысль Михаила). В мире экономики все измеряется в совершенно понятной оси координат – деньги. Уровень капитализации даже такой небольшой (по сравнению с SAP) компании как Navision на порядки превышает общую капитализацию 1С + БЕСТ + Галактика + Парус + остальные. Это однозначная, формализованная оценка всех параметров компании (накопленный опыт, созданные решения, количество и профессиональность персонала, партнеры, клиенты и мн.др.) и показатель возможностей.
Добавим внешние факторы, которые определяют результат деятельности компании:
1) История формирования процессов управления бизнесом
2) История развития систем
Для постиндустриального мира это опыт сотен и десятков лет соответственно. Пока Россия шла своей дорогой, лидерами были отобраны жизнеспособные решения, сформированы стандарты.
В плане бизнес культуры, мы в роли догоняющих. Где точка отсчета для новой экономики, и какой опыт наших производителей ПО? Они изобретали заново велосипед. Потому что, большинство предприятий, задачи которых они решают, находятся в «каменном веке». Какой ERP? Бухгалтеры толком не знают корреспонденцию счетов (сокровенное знание главбуха и его зама). А многие ли в софтверных компаниях знают, что такое сетевой график производства? Прогноз движения денежных средств? Перечислять все не имеет смысла. Excel + 1С – адекватное решение / предел мечтаний для большинства.

Мысль использовать в качестве оценки трудозатраты грамотная, но отражает лишь существующий факт затрат на создание системы.
Можно расширить/усложнить ряд критериев для оценки функциональности системы (трудозатраты/продолжительность/квалификация):
- Количество функций
- Качество функциональности (наглядность, логичность, полнота, наличие ошибок)
- Соответствие стандартам и/или ключевым требованиям прикладных областей
- Опыт использования системы/функций
- Технологичность реализации функций (масштабируемость, открытость, надежность, соответствие технологическим стандартам, трудозатраты на модификации, распространенность технологий, универсальность)
- Адекватность функциональности текущей модели бизнес процессов предприятия
- Стоимостные показатели (системы, оборудования, внедрения, доработки, поддержки, персонала)
- Временные показатели (на переход компании к использованию системы или ее отдельных функций)
Предлагаю дополнить или поправить.

С практической стороны правильнее будет пойти не от оценки функциональности системы, а от оценки и формализации требований заказчика. После чего сопоставить предлагаемые поставщиками решения. Иначе актуальной станет цитата журналистами «Computer World» руководителя отдела внедрений компании «Columbus IT Partner»: «Внедрение системы в компании, есть явление драматическое».


P.S. Совсем непонятно, зачем ставить 1С на металлургическом комбинате.

С уважением.

[Михаил Андреев]

Цитата:

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

Здесь полностью согласен. Любая классификация ПО не устроит заказчика. Грубо говоря, мне не важно, в каком стиле сшит пиджак, главное "чтоб костюмчик сидел". Выбор программы со стороны клиента выглядит не как сравнение разных систем между собой (а, это на Oracle - круто , а на SQL - плохо ). По большому счету ему это неважно. А смотрит он, как его требования могут быть удовлетворены в рамках той или иной системы. Но проклассифицировать требования потенциальных заказчиков, по-моему, задача еще более сложная, чем классификация программ. Во втором случае хоть понятно, с чем мы имеем дело. А в случае с клиентом, то его требования зачастую непонятны и, вдобавок, противоречивы. Поэтому, наверное, мы и обсуждаем не формализованные требования каких-то групп заказчиков (отраслевые решения), а свойства конкретных систем.

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

Цитата:

P.S. Совсем непонятно, зачем ставить 1С на металлургическом комбинате.

Признаться, мне тоже Но ведь ставят

Чтобы не быть голословным, не поленился, и даже нашел ссылку http://www.itrp.ru/content/company/c...xamples/06.asp

[cd_racer]

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

Столкнулся с такой ситуации в секторе АБС - приходит банк к разработчику, а что хочет - сам толком сказать не может. Тут уж от этапа обследования зависит, насколько заказчик и разработчик поймут друг друга и какой результат будет. Могу лишь предположить, что разработчик в качестве критериев часто предлагает технологические моменты (производительность, ресурсоемкость системы, там на каких платформах работать будет, некоторые абстрактные вещи - такие как модульность, функциональность). Заказчик же подходит со стороны задачи: "У меня есть пять складов, три магазина, все это в 4 разных городах, в разных областях, вот как бы мне толком учет наладить, чтоб головной боли не было". Т.е. заказчик идет от конкретных задач, а не от существующих возможностей системы.

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

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

Успехов!