Заказчики разработки информационных систем далеко не всегда понимают все особенности владения такими системами. Спасибо, кэп, ведь если понимают, то они сами эксперты в ИТ. Для всех остальных рассмотрим типовые проблемы, которые из-за этого возникают.
Информационная система совсем “не так материальна”, как какой-нибудь станок – она где-то там в Интернете. На самом же деле информационные системы схожи с другими техническими активами по крайней мере в следующем:
- Наличие операционных расходов;
- Необходимость технического обслуживания;
- Конечный срок эксплуатации.
Операционные расходы
Наличие операционных расходов на сегодня пожалуй наиболее понятная для заказчиков особенность. Во времена доминирования программ, устанавливаемых с CD-дисков, операционные расходы для заказчика/владельца были близки к нулю. Тогда они распределялись по потребителям в виде их затрат на электричество, амортизацию компьютеров и тому подобное. Думаю оттуда растут ноги видения, что владение информационной системой не накладывает операционных расходов, но увы оно безнадежно устарело.
Заказчики сайтов сталкиваются с необходимостью ежемесячно/ежегодно платить за хостинг. Это то самое электричество, Интернет-трафик, амортизация вычислительных ресурсов и т.п. Так же приходится платить ICANN и регистраторам за удержание за собой прав на домены. Этот OPEX возник с появлением Интернета. В случае использования коробочных SaaS-продуктов операционные расходы очевидно заложены в стоимость использования. Различные OPEX-ы владельцев SaaS-продуктов, связанные с эксплуатацией, могут составлять существенной часть всех операционных расходов компании.
Что с этим делать? Понять и простить. Учитывать в долгосрочном финансовом планировании. Главное не питать вредных иллюзий.
Техническое обслуживание: с чем его едят
Даже во времена доминирования программ, устанавливаемых с CD-дисков, заказчик/владелец не мог избежать расходов на техническое обслуживание. Но тогда циклы технического обслуживания могли быть длительными и владелец мог избегать их до поры до времени. Но откуда же они берутся?
И тогда, и особенно сейчас мир ИТ не стоит на месте, его развитие наоборот ускоряется год от года. А значит выходят обновления драйверов, операционных систем и многочисленного ПО, построенного на их основе.
Современная разработка немыслима без заимствования наработок сообществ соответствующих технологий, в частности проектов с открытым исходным кодом (open source). Это выражается в использовании многочисленных библиотек и фреймворков для решения типовых задач в контексте конкретного проекта. Изобретать велосипед в конкретном проекте в большинстве случаев не имеет никакого экономического смысла.
И конечно же подавляющее большинство таких библиотек и фреймворков не стоит на месте. Исправляются ошибки, появляются новые функции, латаются дыры в безопасности.
Эту ситуацию как нельзя удачно иллюстрирует крылатая фраза:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Л. Кэрролл, “Алиса в стране чудес”
Техническое обслуживание: как его готовить
Да, нужно заниматься регулярным техническим обслуживанием информационной системы. Причем как её исходного кода, так и выполняющих её вычислительных ресурсов – серверов, не суть виртуальных или bare metal.
“Да плевать я хотел” – скажет незадачливый заказчик/предприниматель – “у меня и так забот/расходов хватает, чтоб вашего брата ИТ-шника подкармливать регулярно.”
Скепсис тут ясен и каждый волен управлять своей собственностью – пусть и интеллектуальной – как ему заблагорассудится. Отсутствие регулярного технического обслуживание чревато следующими малоприятными вещами:
- Накоплением в продукте все большего количества дыр в безопасности. Это в итоге сделает его лакомым куском не только для хакеров средней руки, но и для откровенных script kiddie-хулиганов. Оценить риски взлома/дефейсинга для бизнеса полезно каждому собственнику.
- Отсутствием возможности исправить ошибки в продукте, которые имеют своей первопричиной ошибки в устаревших библиотеках/фреймворках.
- Чем больше устаревание информационной системы, тем больше затраты на её модификацию. Выражаться это может по-разному. Могут начаться проблемы с поиском подрядчика на доработки конкретного антиквариата. Или ценник найденного подрядчика вдруг окажется сильно больше, чем за это было уплачено пару лет (или пятилеток) тому назад.
Оптимальным решением этой задачи я считаю наличие специально обученного человека в штате, у которого будет стоять такая задача помимо прочего. Аутсорсинг тоже в теории возможен, но там сложнее мотивировать делать эту работу хорошо. Это совсем вкратце, вопросы процесса грамотного владения/управления информационными системами тянут даже не на отдельную статью, на отдельный цикл статей.
Срок эксплуатации
Видимо из-за все той же “нематериальности” информационных систем складывается ощущение, что их можно эксплуатировать вечно. Действительно, чего ей сделается! Ну сервак полетел, поменяли, делов-то. Тсс – по факту и с этим не всё так просто! Но сейчас не об этом.
Сама информационная система концептуально действительно может существовать условно вечно – пока есть спрос на её функционал. Проблема в реализации системы. Технологии приходят и уходят, и с этим связан смена технологических укладов.
Газовое освещение было довольно распространено до того, как было вытеснено электрическим. Газовые осветительные приборы сохранились в основном в музеях. Технических специалистов по таким приборам пожалуй не осталось, они интересуют разве что историков.
Аналогично информационная система созданная при “газовом” технологическом укладе оказывается за бортом с приходом технологического уклада “электрического”. Конечно можно и в 2020-м году на паровом двигателе пытаться ездить, вот только зачем?
Временам доминирования программ, устанавливаемых с CD-дисков, пришел конец с приходом цифровой дистрибуции и развитием Интернета. Еще одним революционным шагом стало массовое распространение мобильных компьютеров, изменившее и сам облик Интернета, и поведение потребителей.
Это всего два и ОЧЕНЬ значительных примера смены технологических укладов, которые в меньшем масштабе происходят намного чаще. Представьте современного вендора, пытающегося продать софтину на массовом рынке, какое-нибудь ведение заметок к примеру. При этом она устанавливается только на десктопах Windows. И сидюшку с дистрибутивом получите по почте. Представили?
Оптимально заблаговременно отслеживать тенденции и закладывать вложения в модернизацию существующих информационных систем в долгосрочном финансовом планировании.
В чем вообще состоит владение?
Само понятие владения информационной системой не так прозрачно, как владение материальным активом. Последний у тебя просто есть. А что на практике значит владеть программным продуктом? Как минимум следующие вещи:
- Наличие эксклюзивных прав на систему как интеллектуальную собственность.
- Наличие возможности санкционировать доступ ко всем составляющим системы:
- исходному коду;
- вычислительным ресурсам, исполняющим систему;
- учетным записям сторонних сервисов и т.п.
Первое все еще иногда упускается в договорных отношениях с подрядчиком, но все же реже становится источником проблем. Важно помнить, что само по себе наличие контракта на выполнение работ не предполагает автоматическую передачу эксклюзивных прав на результат. А вот авторство к примеру вообще не отчуждается по нашему праву.
Вторая категория все еще довольно распространена. Подрядчики далеко не всегда информируют заказчиков на эту тему. Ими могут руководить как банально лень, так и корыстный умысел сохранить контроль в своих руках как рычаг давления в будущем. Или как способ навязывать свои услуги на более интересных чем до этого условиях.
Я очень рекомендую не упускать последний момент из виду. Опять таки наличие специально обученного человека в штате, озадаченного этим вопросом, помогает избежать проблем.
Вместо заключения
Все описанные особенности можно и нужно учитывать в долгосрочном бизнес-планировании.
При принятии решения build vs buy для конкретной информационной системы об этих особенностях забывать никак нельзя. От OPEX в том или ином виде никуда не уйти. А вот бремя и технического обслуживания, и срока эксплуатации при выборе варианта buy ложится на вендора решения.
Хорошо работает наличие в руководстве компании человека с технологической экспертизой, мотивированного долгосрочным успехом этой компании.
2 thoughts on “Владение информационной системой: ликбез”
Comments are closed.