К ИТ-системе поддержки бизнеса пользователь предъявляет одни и те же конечные требования независимо от того тиражируемая она или заказная. Вместе с тем в случае заказной системы имеется возможность более детально учесть требования заказчика, а следовательно и более тонкие нюансы, характерные для внедрения, эксплуатации или развития ИС. На практике эти нюансы могут оказаться весьма значимыми.
Этап внедрения для любой информационной системы - это момент истины. То, что создавалось в течение нескольких месяцев в рамках довольно узкой рабочей группы, выносится на суд бизнес пользователей. Даже если система долго и тщательно тестировалась на стенде, перенос ее в реальную рабочую среду может принести множество неожиданностей. Например, система сделана профессионально и отлично работает, но отвергается пользователями. Или оказывается, что производительность системы в реальных условиях сильно отличается от результатов испытаний на стенде.
В случае заказных систем - и в этом одно из их ключевых отличий от тиражных решений - успех внедрения закладывается на начальном этапе сбора требований и проектирования. От того, насколько глубоко будут учтены потребности и особенности бизнес-пользователей, режим эксплуатации и инфраструктура, в которой системе предстоит работать, во многом будет зависеть, насколько гладко и успешно пройдет внедрение, насколько быстро "приживется" система, какие потребуются затраты на ее дальнейшее сопровождение. Тиражные же системы предполагают большую предсказуемость в плане функционала системы, но неизбежно налагают определенные ограничения на этапе внедрения - какими бы гибкими они не были.
В этой статье пойдет речь о ключевых моментах, которые, по нашему опыту, определяют успех и эффективность внедрения заказных решений. При этом в качестве критериев успешности внедрения будем использовать такие распространенные характеристики, как:
- соответствие требованиям бизнес пользователей;
- стоимость и сроки внедрения и сопровождения;
- готовность к эксплуатации в терминах надежности, производительности и т. д.
Ориентация на бизнес-пользователей
Как показывает практика, будущий успех системы у бизнес-пользователей определяют не только и не столько полнота функционала системы, сколько удобство работы с ней, простота в освоении.
Проектируя интерфейс пользователя, необходимо учитывать уровень подготовки специалистов, которым предстоит работать с приложением, а также назначение приложения. Если пользователи имеют большой опыт работы с программными приложениями, то можно использовать многооконный интерфейс, выпадающие меню и т. д. Если же речь идет о сотрудниках, для которых сложно "двумя руками три кнопки нажать", то интерфейс системы должен быть как можно более простым, а последовательность действий - очевидной. Аналогично, если в режиме использования критичен быстрый ввод данных, то на первое место выходит удобство интерфейса. А если система должна помогать в привлечении новых клиентов, то здесь важную роль играет внешний вид: по тому, насколько приятным, проработанным, дружелюбным он выглядит, будущие клиенты судят об услугах компании. В нашей практике недавно был случай, когда западная компания, которая работает в сфере страхования, была вынуждена по этой причине полностью переработать интерфейс и технологию работы приложения, посредством которого компания предлагала свои услуги. Вообще, в последнее время важность факторов эргономики осознают многие разработчики, и интерфейс пользователя для масштабных систем на этапе проектирования обычно проходит специальное тестирование на эргономичность с привлечением специалистов в этой области, а еще два-три года назад это было большой редкостью.
Второй момент - это сохранение привычного стиля работы пользователей. В отличие от готовых приложений, при внедрении заказных систем гораздо больше возможностей обеспечить преемственность, и это одно из преимуществ, которое необходимо учесть и использовать. Например, если пользователи привыкли готовить рабочие отчеты в формате Excel и этот формат является для них привычным и знакомым, то желательно сохранить эту возможность и в новом приложении. Если пользователи привыкли к определенной последовательности и формату ввода данных, например при оформлении контракта с клиентом, - желательно оставить ее без изменений. Понятно, что при разработке новой системы функционал становится шире, а бизнес-процессы могут существенно меняться. Но наличие при работе с системой знакомых, привычных элементов поможет преодолеть сопротивление пользователей, а также существенно сократить сроки обучения на этапе ввода системы в эксплуатацию.
Этап описания функционала системы - создания функциональных спецификаций, как правило, хорошо знаком и заказчикам и разработчикам. Степень успеха зависит здесь в основном от грамотности и добросовестности аналитиков, которые в ходе обследования фиксируют требования пользователей. Тем не менее хотелось бы остановиться на двух важных аспектах, которые касаются вопросов удобства пользователей и необходимости неформально вовлекать бизнес-пользователей в процесс создания системы.
Распространенная ошибка при проектировании системы - реализация описанного в задании функционала без учета специфики выполнения операций теми или иными категориями пользователей (ролями). В общем случае задачи, которые руководство ставит конкретным специалистам, могут значительно отличаться от общих целей внедрения системы. Как правило, для выполнения этих задач сотрудники формируют свою, удобную им, среду. Поэтому на этапе сбора требований важно понять, как, в какой последовательности операции выполняются сейчас, чтобы предложить пользователям новый инструмент, который будет - как минимум - не менее удобным, чем существующий. Такой подход гарантирует, что ни одна из категорий пользователей не окажется в проигрыше при внедрении системы, и позволит быстрее преодолеть сложности внедрения, связанные с сопротивлением новым методам работы.
Еще одна типичная ситуация - когда будущие пользователи относятся к этапу постановки задачи весьма формально, как на этапе сбора требований, так и на этапе утверждения спецификаций. В результате часто случается, что ряд принципиально важных требований, связанных с технологией работы, оказывается неучтенным на начальном этапе. И чем позже это несоответствие обнаруживается, тем выше стоимость его устранения. Если в разработке участвует внешний исполнитель, то возникает неизбежный конфликт - заказчик не принимает систему, потому что она не делает того, что нужно пользователям (или делает не так), а исполнитель справедливо утверждает, что сделано все так, как заказано, и ссылается на утвержденные спецификации. Чтобы избежать такой ситуации, используют целый ряд стандартных методик, которые несколько увеличивают сроки создания системы, но помогают исключить описанную ситуацию. Прежде всего это использование технологии прототипирования, чаще всего бизнес-логики и пользовательского интерфейса.
В качестве пояснения приведу пример создания системы идентификации для сборочного производства. На этапе обследования основные требования к системе были выявлены, оформлены в спецификации и согласованы. Однако когда в руки специалистам дали первый рабочий прототип системы, разговор пошел уже совершенно на другом уровне. Выявились такие нюансы ее использования в реальных условиях, которые не смог бы выявить ни один аналитик.
Условия эксплуатации
Чтобы внедрение и дальнейшее сопровождение заказного решения были действительно эффективными и малозатратными, на этапе проектирования системы необходимо максимально учесть будущие условия эксплуатации, в том числе:
- Географию и режим использования. Будет ли система внедрена только в центре или одном филиале, или она покрывает все отделения компании? Должна ли информация быть доступна в оперативном режиме, или достаточно определить регламенты обновлений? Должны ли пользователи иметь возможность доступа к системе вне офиса?
- Требования к каналам связи. Какая система коммуникаций будет использоваться для обмена данными между отделениями? Требуется ли обеспечение надежной работы по dial-up каналам? Уровень безопасности и так далее.
- Требования к вычислительным ресурсам. Какова мощность рабочих станций? Какие платформы используются в организации? Какие специалисты есть в отделе сопровождения?
- Внешнее окружение и интерфейсы.
Таким образом, условия эксплуатации становятся еще одним важным источником требований к системе, не менее важным для успешного внедрения, чем требования к функционалу. Именно они во многом определяют выбор технических решений. Очевидно, что если в организации используются маломощные компьютеры и не планируется их модернизация в ближайшее время, то необходимо создать такое приложение, которое будет стабильно работать в условиях этих ограничений. В противном случае пользователи будут игнорировать использование нового средства автоматизации. Или если система не интегрирована с другими корпоративными приложениями, то для пользователей это зачастую означает либо неполноту информации, либо дублирование ввода данных. И так далее.
Для территориально распределенных систем особое внимание, конечно, уделяется требованиям к каналам связи, причем с точки зрения не только пропускной способности, но и стоимости трафика. Например, если большой объем данных перекачивается через центральный офис, то, возможно, установка дополнительных серверов, которые замкнут на себя часть нагрузки, окажется дешевле стоимости лишнего трафика.
Для иллюстрации приведу два примера, в которых требования к условиям эксплуатации определили выбор технических решений. И в том и в другом случае речь шла о масштабных распределенных системах, реализованных в трехуровневой архитектуре с единым центром.
В первом случае требовалось, чтобы система имела единую базу данных в центральном офисе и была доступна с любого рабочего места в любом из более чем 100 региональных подразделений компании, без каких-либо предварительных настроек на рабочем месте пользователя. По этой причине, принимая решение о способе реализации основного пользовательского приложения, мы исключили из рассмотрения как "толстого" клиента, так и наиболее популярное на сегодняшний день решение на базе "толстого" клиента с локальным кэшированием справочных данных (смарт-клиента). В этом случае также требовались определенные преднастройки, в первую очередь наличие среды выполнения. Таким образом, требования эксплуатации предопределили выбор тонкого клиента.
Во втором случае, помимо выбора клиентского интерфейса, необходимо было определить механизм доступа к серверу бизнес-логики, который обеспечил бы взаимодействие модулей системы по открытым каналам Internet с возможностью защиты сеанса связи. Кроме того, это должен был быть независимый от разработчика (отчуждаемый) стандарт интерфейса, который обеспечил бы расширяемость и быструю интеграцию с другими - многочисленными - приложениями, а также возможность распараллелить разработку. Все эти требования однозначно определили необходимость использования технологии Web-сервисов.
Выбирая тип пользовательского интерфейса в этом же проекте, необходимо было обеспечить полнофункциональный, эргономичный и быстрый, простой в обновлении интерфейс, который устойчиво работал бы на каналах с низкой пропускной способностью. "Тонкий" клиент был сразу исключен из рассмотрения, поскольку не удовлетворял требованиям удобства и производительности. В пользу "толстого" клиента говорили высокая скорость работы интерфейса пользователя и простота реализации, развитый и удобный GUI; специальные возможности в области интеграции с локальными приложениями и кэширования, а также меньший объем участвующих в обмене данных и возможности защиты приложения. В то же время нужно было учитывать и такие недостатки, как необходимость реализации механизма обновления версий, отсутствие мультиплатформенности и возможности легкого встраивания пользовательского интерфейса системы в другие приложения (портал). В итоге предпочтение отдали смарт-клиенту, на котором хранятся только медленно меняющиеся данные (справочники и др.), а рабочие данные уходят непосредственно на сервер.
Планирование внедрения и сопровождения
Вне зависимости от того, кем создается система - внутренней или внешней командой разработчиков, - этап внедрения должен планироваться и контролироваться ИТ-службой предприятия. Его можно рассматривать как самостоятельный проект, который включает:
- опытную эксплуатацию и доработку системы по ее итогам;
- развертывание или проверку инфраструктуры (сервера, каналы связи и т. д.);
- обучение пользователей;
- обеспечение техподдержки.
Не останавливаясь на общеизвестных моментах, хотелось бы отметить, что знакомство пользователей с системой в ходе внедрения не стоит проводить в фоновом режиме. На это должно специально выделяться время по согласованию с бизнес-руководителями. Только в этом случае есть шанс, что система не будет восприниматься пользователями как еще одна проблема в и без того перегруженном рабочем графике.
Необходимо отметить, что со сдачей заказного решения в промышленную эксплуатацию проект не заканчивается. Практически всегда в ходе эксплуатации системы возникают все новые и новые требования, которые предполагают выпуск плановых обновлений. Таким образом, недостаточно организовать "горячую линию" для пользователей. Команда сопровождения и развития заказных систем должна включать также аналитика, который занимается сбором и анализом новых требований и замечаний, а также ресурсы разработчиков, которые занимаются выпуском новых версий. Разумеется, речь идет не о полной, а частичной занятости специалистов, и обычно на сопровождение корпоративной системы требуется в среднем не более 1-2 человеко-месяцев.
Принимая у поставщика готовую систему, важно проследить, чтобы вместе с конечным продуктом и исходными кодами (если он создавался на заказ) были переданы и все данные по истории изменения системы. Поставляемый продукт представляет собой не только выполняемые модули, но и всю информационную инфраструктуру, которая поддерживает его сопровождение и развитие. Эта информация имеет большую ценность для его дальнейшего развития. История развития продукта должна передаваться в ходе внедрения в согласованном виде вместе с инфраструктурой, поддерживающей внесение этих изменений. Поставщик обязан организовать этот процесс у себя, а по завершении проекта передать все материалы и механизм их обновления заказчику. Если контрактор не может обеспечить целостность и сохранность этой информации, то заказчик попадает в монопольную зависимость от него - продукт перестает быть "отторгаемым" от поставщика. С одной стороны, это очевидно. С другой стороны, в договоре с поставщиком, как правило, прописано, что и когда необходимо поставить, но не прописано, что вся информация, связанная с внедрением (замечания, требования, история изменений), также принадлежит заказчику и должна передаваться в ходе поставки..
Организация взаимодействия в проекте
В заключении хотелось бы сказать несколько слов об организации взаимодействия в проекте.
При внедрении заказных решений очень важно, чтобы заказчик имел возможность наблюдать за ходом реализации проекта на всем его протяжении. Если исполнитель предлагает заказчику "черный ящик", на входе которого исходные спецификации, а на выходе - готовая система, то со стопроцентной гарантией полученный продукт будет непригоден к использованию. Идеальная ситуация - когда не только координаторы со стороны ИТ-департамента, но и представители бизнес-заказчика являются активными членами рабочей группы, участвуют в обсуждениях итогов по этапам, вносят замечания.
Если речь идет о масштабном проекте, то обеспечить его прозрачность и управляемость помогает организация единого информационного пространства для участников проекта - проектного репозитария, который позволяет формализовать такие процессы, как сбор замечаний и новых требований, версионный контроль, планирование и т. д.
Если разработка системы ведется несколькими группами разработчиков - например, частично на стороне исполнителя, частично на стороне заказчика, - то современные средства поддержки разработки позволяют организовать единые распределенные процессы управления требованиями, конфигурациями, изменениями. При этом всем участникам проекта обеспечивается доступ к проектному репозиторию через Web.
Заключение
Эта статья не создавалась как руководство по внедрению заказных приложений. Мы лишь хотели акцентировать внимание читателей на тех моментах, которые, по нашему наблюдению, часто остаются за кадром плана внедрения и снижают успешность проекта.
Если сравнивать полный цикл внедрения заказных и тиражных систем, то, в общем случае, можно сказать, что затраты на внедрение заказных и тиражных решений различаются на разных этапах. В случае тиражных решений на этапе сбора требований, настройки и доработки системы обычно работает небольшая группа консультантов, как правило внешних. На этапе же внедрения, особенно если речь идет о распределенной системе, требуются гораздо большие усилия, более мощная команда внедренцев. Для заказной системы - наоборот, пик ресурсных затрат максимален вначале, на этапе проектирования и разработки. Если все организовано и спланировано правильно, то этап внедрения обычно проходит быстрее и менее болезненно, поскольку система создавалась специально с учетом специфики данной организации, и многие потенциальные проблемы уже были учтены.
В проекте, помимо ИТ-службы, задействованы и бизнес-пользователи, и специалисты исполнителя. Но ответственность за организацию проекта, как правило, лежит на координаторах со стороны ИТ. И их задача - решить ключевые вопросы, о которых шла речь выше. А именно - обеспечить эффективное взаимодействие исполнителя с бизнес-пользователями, соответствие поставляемого продукта реальным условиям эксплуатации, возможности сопровождения, а также наличие квалифицированного персонала для поддержки на местах.
