SaaS – Архитектура ИТ-решений

SaaS в России: Интранет и e-Learning

Продолжаю серию рождественских гаданий темой программное обеспечение как услуга (SaaS). Просмотрев материалы прошлогодних конференций, публикации и сообщения в блогах на тему SaaS практически не нашел ни одной идеи которая могла бы стать локомотивом или, как говорят связисты killer application, SaaS в России. Набор предоставляемых услуг достаточно скуден: антивирусы, сайты-визитки и электронные магазины(витрины), немножко CRM, немножко складского учета, немножко проектного управления. Запишем в активы SaaS в России базы законов и подзаконных актов, адресов и геосистемы для тех, кому они нужны – вот, пожалуй, и все. Приложения, способного перевести SaaS из увлечения энтузиастов в востребованную услугу в этом списке отыскать сложно. Востребованным, быть может, станет работа с персоналом. Я имею в виду не кадровое делопроизводство, а обучение, аттестацию, развитие, внутренние коммуникации и управление знаниями. Частично эти функции уже одной ногой в Интернете. Подбор персонала переехал в Интернет так давно и так незаметно что, кажется, он там всегда и располагался. Насколько мне известно, крупные отечественные компании уже используют западные SaaS сервисы для исследований и оценки персонала. Читать далее SaaS в России: Интранет и e-Learning

Заказная разработка vs. коробочные решения

Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.

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

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

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

Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется