Владение информационной системой: ликбез

Заказчики разработки информационных систем далеко не всегда понимают все особенности владения такими системами. Спасибо, кэп, ведь если понимают, то они сами эксперты в ИТ. Для всех остальных рассмотрим типовые проблемы, которые из-за этого возникают.

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

• Наличие операционных расходов;
• Необходимость технического обслуживания;
• Конечный срок эксплуатации.

Операционные расходы

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

Заказчики сайтов сталкиваются с необходимостью ежемесячно/ежегодно платить за хостинг. Это то самое электричество, Интернет-трафик, амортизация вычислительных ресурсов и т.п. Так же приходится платить ICANN и регистраторам за удержание за собой прав на домены. Этот OPEX возник с появлением Интернета. В случае использования коробочных SaaS-продуктов операционные расходы очевидно заложены в стоимость использования. Различные OPEX-ы владельцев SaaS-продуктов, связанные с эксплуатацией, могут составлять существенной часть всех операционных расходов компании.

Что с этим делать? Понять и простить. Учитывать в долгосрочном финансовом планировании. Главное не питать вредных иллюзий.

Техническое обслуживание: с чем его едят

Даже во времена доминирования программ, устанавливаемых с CD-дисков, заказчик/владелец не мог избежать расходов на техническое обслуживание. Но тогда циклы технического обслуживания могли быть длительными и владелец мог избегать их до поры до времени. Но откуда же они берутся?

И тогда, и особенно сейчас мир ИТ не стоит на месте, его развитие наоборот ускоряется год от года. А значит выходят обновления драйверов, операционных систем и многочисленного ПО, построенного на их основе.

Современная разработка немыслима без заимствования наработок сообществ соответствующих технологий, в частности проектов с открытым исходным кодом (open source). Это выражается в использовании многочисленных библиотек и фреймворков для решения типовых задач в контексте конкретного проекта. Изобретать велосипед в конкретном проекте в большинстве случаев не имеет никакого экономического смысла.

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

Эту ситуацию как нельзя удачно иллюстрирует крылатая фраза:

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

Л. Кэрролл, “Алиса в стране чудес”

Техническое обслуживание: как его готовить

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

“Да плевать я хотел” – скажет незадачливый заказчик/предприниматель – “у меня и так забот/расходов хватает, чтоб вашего брата ИТ-шника подкармливать регулярно.”

Скепсис тут ясен и каждый волен управлять своей собственностью – пусть и интеллектуальной – как ему заблагорассудится. Отсутствие регулярного технического обслуживание чревато следующими малоприятными вещами:

• Накоплением в продукте все большего количества дыр в безопасности. Это в итоге сделает его лакомым куском не только для хакеров средней руки, но и для откровенных script kiddie-хулиганов. Оценить риски взлома/дефейсинга для бизнеса полезно каждому собственнику.
• Отсутствием возможности исправить ошибки в продукте, которые имеют своей первопричиной ошибки в устаревших библиотеках/фреймворках.
• Чем больше устаревание информационной системы, тем больше затраты на её модификацию. Выражаться это может по-разному. Могут начаться проблемы с поиском подрядчика на доработки конкретного антиквариата. Или ценник найденного подрядчика вдруг окажется сильно больше, чем за это было уплачено пару лет (или пятилеток) тому назад.

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

Срок эксплуатации

Видимо из-за все той же “нематериальности” информационных систем складывается ощущение, что их можно эксплуатировать вечно. Действительно, чего ей сделается! Ну сервак полетел, поменяли, делов-то. Тсс – по факту и с этим не всё так просто! Но сейчас не об этом.

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

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

Аналогично информационная система созданная при “газовом” технологическом укладе оказывается за бортом с приходом технологического уклада “электрического”. Конечно можно и в 2020-м году на паровом двигателе пытаться ездить, вот только зачем?

Временам доминирования программ, устанавливаемых с CD-дисков, пришел конец с приходом цифровой дистрибуции и развитием Интернета. Еще одним революционным шагом стало массовое распространение мобильных компьютеров, изменившее и сам облик Интернета, и поведение потребителей.

Это всего два и ОЧЕНЬ значительных примера смены технологических укладов, которые в меньшем масштабе происходят намного чаще. Представьте современного вендора, пытающегося продать софтину на массовом рынке, какое-нибудь ведение заметок к примеру. При этом она устанавливается только на десктопах Windows. И сидюшку с дистрибутивом получите по почте. Представили?

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

В чем вообще состоит владение?

Само понятие владения информационной системой не так прозрачно, как владение материальным активом. Последний у тебя просто есть. А что на практике значит владеть программным продуктом? Как минимум следующие вещи:

• Наличие эксклюзивных прав на систему как интеллектуальную собственность.
• Наличие возможности санкционировать доступ ко всем составляющим системы:
  • исходному коду;
  • вычислительным ресурсам, исполняющим систему;
  • учетным записям сторонних сервисов и т.п.

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

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

Я очень рекомендую не упускать последний момент из виду. Опять таки наличие специально обученного человека в штате, озадаченного этим вопросом, помогает избежать проблем.

Вместо заключения

Все описанные особенности можно и нужно учитывать в долгосрочном бизнес-планировании.

При принятии решения build vs buy для конкретной информационной системы об этих особенностях забывать никак нельзя. От OPEX в том или ином виде никуда не уйти. А вот бремя и технического обслуживания, и срока эксплуатации при выборе варианта buy ложится на вендора решения.

Хорошо работает наличие в руководстве компании человека с технологической экспертизой, мотивированного долгосрочным успехом этой компании.