Андрей Орлов - Записки автоматизатора. Профессиональная исповедь

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

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

Конечно, любую систему можно доработать до состояния, когда она вас удовлетворит (например, переписав заново все, кроме логотипа). Но на мой взгляд, учитывая, что зарубежная система обойдется вам в 2−10 раз дороже аналогичных российских, выбор таких систем сейчас должен иметь очень существенные основания, например, наличие функциональности, которой нет в отечественных системах. Но если этого требует ваш зарубежный совладелец, куда же вы денетесь…

Кстати, о логотипе. Не забывайте сами и не уставайте напоминать руководству, что корпорации Microsoft Inc. не разрабатывала систем Navision и Axapta [1]

Она купила фирму Navision вместе с ее программными продуктами, [2]поэтому ждать от этих продуктов исключительной совместимости с продуктами Microsoft не нужно. Равно как не нужно надеяться, что при разработке этих продуктов использовались соответствующие технологические стандарты корпорации Microsoft. Компания SAP пошла еще дальше: она купила продукт, который сейчас продает под названием SAP Business One, у израильских разработчиков, не купив при этом самих израильских разработчиков, так что самостоятельно не может даже исправить ошибки в этом продукте. Настоящие «Жигули» с официально установленной трехлучевой звездой от «Мерседеса».

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

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

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

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

Как истинный ретроград, я предпочитаю смотреть на модель «сущность−связь» (ER-модель), но годится и любая другая общеизвестная модель, лишь бы она была описана в литературе, а не придумана самими разработчиками.

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

Многие западные системы поставляются с «готовой» методологией внедрения (фактически это перечень шагов развертывания системы в идеальном мире, некий «сферический конь в вакууме»). Частью таковой обычно является и типовой план, выглядящий примерно так:

1. Продажа лицензий и установка системы (конечно же, самый главный и своевременный этап);

2. Обучение;

3. Концептуальное понимание;

4. Функциональное описание;

5. Разработка;

6. Внедрение;

7. До свидания.

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

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