ManageExpert.ru

Успешный менеджмент

Выбор системы

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

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

Документы разработчика: стандарт предприятия на разработку программного обеспечения.

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

Документы разработчика: модель базы данных.

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

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

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

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

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

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

2. Обучение;

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

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

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

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

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

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

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

Перейти на страницу: 1 2 3 4 5 6 7 8 9