Как "советуют" выбирать программу для автоматизации

Предисловие

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

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

Вот и недавно попались под руку материалы одного из семинаров с такими "советами", которые и стали поводом для написания этого иронического экспромта, с точки зрения участника с другой стороны процесса автоматизации.

"Бизнес-цели" или начало выбора

Для начала будущему пользователю программы в лице руководства предприятия рекомендуется определиться с целями. Цитирую:

"Начните с определения бизнес-целей, которые должны быть:

• Конкретными
• Имеющими денежное выражение
• Детализированными

Как это может выглядеть:

• Оцените ваш план развития
• Оцените рынок и стратегию работы на нем
• Определите текущие проблемы
• Определите причины, их вызывающие".

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

Реально же программы автоматизации приобретаются чаще всего в двух случаях:

1. Когда уже очевидно, что без такой программы не обойтись - компания либо теряет доходы, либо хочет их увеличить.
2. Когда такие программы уже есть у конкурентов - это верный признак того, что пора перестать комплексовать по поводу "экономической целесообразности" и отнестись к автоматизации как к "осознанной необходимости".

Шаг второй - критерии выбора

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

Список рекомендаций по этому поводу выглядит следующим образом:

• "Составить полный список необходимых функций с указанием приоритетов (или этапов) и сложности реализации - shopping list.
• Попросить поставщиков указать - какие из функций входят в базовую функциональность, какие требуют доработки.
• Сделать сквозной анализ каждой функции".

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

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

А ведь здесь еще рекомендуется и указать "приоритеты", и "сложность реализации", и "сделать сквозной анализ каждой функции"!?

Техническое задание - финиш или начало движения?

Приведем образец такого списка функций, составленного в одной из компаний, оказывающей услуги по ремонту автомобилей.

"Программа для диспетчерской"

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

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

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

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

Некоторые мифы о том, как "надо выбирать программу"

В дополнение к вышеприведенным "советам" взглянем изнутри и на некоторые мифы, сопровождающие выбор корпоративного ПО.

Миф 1. Дайте демо-версию

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

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

А поскольку в демо-версиях таких индивидуальных настроек нет, то и программа кажется чужой, не удобной, которая не подходит под потребности компании.

Миф 2. Где работает ваша программа, как на нее посмотреть?

Еще один "верный" способ решить вопрос.

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

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

Еще одну точку зрения выразил генеральный директор производственного предприятия, внедрившего недавно "1С 8.0 УПП": "А зачем мне просто так рассказывать о том, за что я заплатил деньги?".

Миф 3. Сколько лет вы работаете на рынке?

Некоторым заказчикам кажется, что таким хитрым вопросом они обезопасят себя от фирм-однодневок.

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

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

Притча о "пинчере"

И в заключение притча из программистского фольклора.

"Однажды один человек пошел на рынок, чтобы купить себе собаку-пинчера. Он ходил от одного продавца к другому и спрашивал: "У вас есть пинчер?" Но ни у кого из продавцов пинчера не оказалось.

Так он проходил целый день и пошел с рынка ни с чем. Сразу за воротами сидел бомж. Он увидел грустного человека и спросил у него: "Что ты ищешь?". "Пинчера", - ответил человек. И тогда бомж протянул ему то, что держал в руках, и сказал: "Вот, пинчер"...

Мораль сей басни

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

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

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

В противном случае компания рискует купить "пинчера".

Артем ПРОКСИН