В систему, сданную в эксплуатацию, не должны вноситься изменения

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

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

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

Однако если руководитель бизнеса осознанно идёт на разработку системы собственными силами, это означает, что требования со стороны бизнеса будут изменяться постоянно и заказчик будет требовать их реализации немедленно, а не в течение года до следующей поставки очередной версии системы. Часто эти требования носят далеко не косметический характер и предполагают серьезную доработку (переделку) уже эксплуатируемой системы. При in-house-разработке проектная документация создается с учетом всех реализованных на конкретный момент требований, но требования реализуются и сдаются в эксплуатацию поэтапно. В результате очень редко возникают моменты (если новые требования долго не поступали), когда проектная документация полностью соответствует передаваемой в эксплуатацию системе.

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

Разработчик не должен иметь доступа к «боевой системе»

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

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

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

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

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

Служба эксплуатации должна быть во всеоружии!

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

Против таких доводов устоять невозможно. Безусловно, без документации не обойтись, специалистов службы эксплуатации следует обучить, программы для администрирования пользователей должны быть разработаны, сбор статистки и мониторинг также необходимы. Руководитель постоянно должен планировать проектные работы с учетом этих факторов и на самых ранних стадиях проекта вовлекать в него эксплуатационную службу, чтобы лучше понять требования эксплуатации и начать работать над ними как можно раньше. Равномерное планирование работ над этими требованиями в ходе всего проекта во всех отношениях лучше, чем приостановка проекта «на финишной прямой», перед запуском системы в эксплуатацию, только для того, чтобы залатать допущенные в функциональности или в документации дыры. Тем более, что такие приостановки в глазах заказчика выглядят излишне вызывающе. Но следует учитывать, что все эти работы компания будет «оплачивать» из бюджета проекта. Насколько трудозатратны будут требования по приведению службы эксплуатации во всеоружие? Насколько увеличит бюджет реализация этих требований и насколько к этому увеличению бюджета и сроков будет готов заказчик проекта?

Резюме

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

Но чем это плохо? Только тем, что нет одного ответственного за сбои? Не только: дело в том, что в этих случаях ресурсы проектировщиков не высвобождаются для других проектов. А насколько они велики? Ведь если говорить о проектах закупки и внедрения систем, то они требуют уже других ресурсов…

Подчеркнем еще раз, что разработка программного обеспечения и создание автоматизированной информационной системы (совокупности функциональной части, технического, информационного, программного, организационного обеспечения, коммуникаций и персонала) — это разные не по масштабам, а по содержанию проекты. Программы в основном разрабатываются in-house, включая сложные программные системы. И гораздо реже покупаются в готовом виде. Но «информационные системы» в принципе делаются на заказ. Хотя часто это «внутренний заказ», и разработка системы ведется in-house (собственными силами). Поэтому ввод прикладной системы в действие, например, в банке не означает ее опытную, опытно-промышленную и даже промышленную эксплуатацию. Это — использование системы заказчиком, сопровождение программного обеспечения разработчиком и обеспечение работоспособности (эксплуатации) системы службой поддержки. Развитие информационной системы в ходе постоянной эксплуатации — неизбежность ее жизненного цикла. Не признавать этого — лукавство….

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

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

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

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

Оценка эффективности внедрения информационных технологий

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

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