В последнее время мне часто приходится общаться на тему технической поддержки медицинских информационных систем (МИС). Это происходит и как с нашими заказчиками, так и достаточно много – со специалистами из различных регионов, где работаю наши коллеги-конкуренты. В целом суть этого обсуждения сводится к тому, что собеседники пытаются для себя уточнить – что такое техническая поддержка в нашем понимании, зачем она нужна, почему она является платной или почему оказывается так, а не иначе. Причем форма такого общения весьма разнообразна. От вполне спокойных и резонных вопросов «Что входит в данное понятие?» или «Почему то, что мы хотим – не является на Ваш взгляд техподдержкой?» и до пограничных с гарлапанством вопросов а-ля «Караул, спасайте нашу медицину от воров и проходимцев, которые высасывают последние кровные деньги за профанацию и собственные ошибки».
Такого общения стало действительно много. При этом – если отбросить некоторые эмоциональные перегибы и спокойно вдуматься – почему мы имеем такое явление – становится понятным, что вопрос техподдержки действительно имеет место быть и он, как минимум, – непростой и неоднозначный. Вопросы про техподдержку задают люди разных слоев: руководители региональных систем здравоохранения, специалисты МИАЦ, главврачи, рядовые пользователи и сотрудники медицинских организаций. И вплоть до простых граждан, которые из СМИ, сайта госзакупок или еще откуда-то узнают – что оказывается регион заказывает и оплачивает нечто неведомое под названием «Техподдержка».
То, что разработчики МИС понимают под ней нечто само собой разумеющееся и поэтому не требующее какого-то специального пояснения и разъяснения, на практике играет «злую шутку»: т.к. тему эту толком мы не раскрываем – получается, что люди на местах, включая наших Заказчиков и Пользователей, додумывают ее сами и подчас – весьма сильно искажая этот вопрос. Более того, иногда вопросы по этой теме и не задаются вовсе. Вместо этого – люди, не желая особо разбираться в сути данной темы, интерпретируют те немногие факты, которые им известны и понятны, на свой субъективный взгляд и представляют картину далеко не в том свете, как она задумывалась и применяется на самом деле.
Причина всего этого, как мне сейчас кажется, состоит в том – что люди просто не до конца понимают, как мы видим себе услугу технической поддержки (или технического сопровождения – тут термин не устоялся до конца), а мы (под «мы» я понимаю в широком смысле – разработчиков МИС, внедренцев, специалистов ИТ-служб медицинских организаций, руководителей региональных проектов информатизации и т.д.) это толком и не разъясняем. Не отвечаем на вполне закономерные вопросы. А зря. Нет ничего зазорного или сложного в том, чтобы постараться разъяснить ситуацию и дать людям информацию для того, чтобы они более адекватно и объективно на все это посмотрели.
Так как ответить полноценно на такие вопросы и обсуждения, существующие в разной форме, в короткой переписке или даже телефонном или личном общении – не представляется возможным, решил написать этот пост – чтобы попытаться как-то в комплексе осветить тему техподдержки.
Повторюсь, тема непростая. Точнее – она для нас, ИТ-шников, кажется простой – но для представителей медицинского сообщества – она таковой не является. Поэтому – по ходу дела – я постараюсь приводить примеры из области, которая более понятна будет читателю. Например, возьмем понятную всем тему строительства дома (теплицы, гаража – чего угодно, особо не важно). И начну с такой юмористической байки-присказки. Встречаются Владелец только-только построенного новоиспеченного дома и Строитель. Владелец «В целом я домом доволен – это более/менее то, что я просил. Но вот я тут подумал – мало ли я что-то упустил, когда заказывал дом или вдруг что-то моим домочадцам захочется изменить или достроить или чуть-чуть переделать - можно я к Вам обращусь и Вы сделаете это для меня? Ведь я так много заплатил за дом и Вы так хорошо на этом заработали – почему бы не пойти навстречу?». Старый опытный строитель, слушая это далеко не в первый раз, отвечает «Да, конечно – я Вас понимаю. Вы хороший заказчик и я бы не хотел портить с Вами отношения своим отказом. Только давайте в ответ Вы мне тоже пообещаете – что когда у меня начнутся проблемы или что-то случится – я приду к Вам и Вы заплатите мне еще немного денежек за уже построенный дом просто так, без дополнительной работы - ведь у Вас этих денег так много!».
Уверен, большинство – прочитав эту историю, поймают себя на мысли – что Владелец в целом прав и мы его прекрасно понимаем, а вот Строитель не прав и он так действовать категорически не должен, не правда ли? При этом я на 100% уверен – что так подумают все, КРОМЕ строителей. Но если Вы все таки постараетесь встать на сторону Строителя – то согласитесь, – что деньги он получил за то, что УЖЕ СДЕЛАЛ. Когда Владелец и Строитель договаривались на строительство – они договорились на вполне конечный и понятный объем работ, затрат и времени. А в этом разговоре его просят за эти же деньги теперь делать и переделывать нечто, не имеющее на момент такого разговора границ как в сроках, так и в затратах, сложности да и вообще – реальности выполнения. И получается – что его ответная просьба – по своей сути – имеет точно такое же право на жизнь, как и просьба Владельца. Но при этом ответ Строителя почему-то считается абсурдным, а вот просьба Владельца – нет.
Вот и с техподдержкой медицинских информационных систем ровно такая же история.
Первое, с чего начнем – это разберемся, что такое техподдержка? Думаю, каждый разработчик МИС, впрочем как и разработчики любых других информационных систем, хотя и чуть-чуть по разному формулируют эту услугу, но в целом - понимают. Но если я здесь расскажу о том, как мы видим это в нашей компании К-МИС, то это не будет достаточным ответом. Читатель скажет – что это мы в К-МИС не правы – т.к. все утрируем и упрощаем, а на самом деле – техподдержка – это нечто совсем иное. Поэтому я Вам расскажу не о том, как МЫ это понимаем, а о том – как это понимают признанные лидеры ИТ-отрасли: компании, которые достигли максимальных успехов в области разработки программного обеспечения.
Итак, «наше всё», компания 1-С, на своем сайта так описывает состав базовой поддержки (http://www.1c.ru/rus/support/support.htm):
- доступ для скачивания обновлений на сайте поддержки пользователей системы
- услуги линии консультаций фирмы "1C" по телефону и электронной почте
Второй пример – отечественная компания ABBYY (http://www.abbyy.ru/support/policy/):
Рассматриваемые вопросы. Служба технической поддержки дает рекомендации по:
- установке продуктов ABBYY на любую из операционных систем, указанных в системных требованиях к данному продукту
- активации
- использованию функций, описанных в документации на продукты.
Служба технической поддержки компании ABBYY не занимается:
- обучением работе с компьютером и настройке сети
- программированием или созданием пользовательских модулей или решений
- консультацией по вопросам использования или конфигурации сторонних продуктов.
Смею утверждать, что и у мировых гигантов – Microsoft, IBM, Oracle и т.д. – техническая поддержка, как правило включает следующее:
- Доступ к скачиванию и установке обновлений ПО
- Возможность задать вопрос по вполне оговоренной тематике (тому ПО, которое выпускает данный вендор)
- Доступ к различным информационным ресурсам – сайтам техподдержки, библиотекам технической документации, форумам и т.д.
- Возможность сообщить об ошибке в программном продукте или предложить разработчикам какую-то идею или улучшение в нем.
Проблема, которую имеют на сегодня разработчики МИС, состоит в том – что такой состав услуги технической поддержки Заказчик и Пользователи МИС нередко считают для себя неприемлемым. Вместо того, чем является техподдержка на взгляд разработчика - достаточно часто пользователи воспринимают ее как обязанность выполнять любое пожелание и решать любую проблему или задачу, возникающую на проекте. Т.е. вместо «возможности скачивать и бесплатно устанавливать новые версии ПО» мы имеем ожидание «переделывать МИС по нашим указаниям – быстро, качественно и бесплатно». Вместо «возможности задать вопрос по конкретно обозначенным темам» имеет место быть «У нас тут какая-то проблема случилась – вот берите ее и разбирайте – чтобы к утру все было устранено».
В каком-то смысле – отвечая на вопрос, что такое техподдержка – нужно иметь в виду, что это некое гарантийное сопровождение Заказчика и Пользователя, но не обязательство в течение срока техподдержки решать возникающие новые задачи и «хотелки». В нашем с вами жизненном примере – если посмотреть на все это глазами Строителя, ситуация выглядит так: Владелец дома требует, чтобы вместо того – чтобы обсуждать и разбирать кажущиеся ему недостатки выполненного ранее строительства, которые он по ходу жизни находит в своем доме – Строитель должен достроить новый этаж, приделать террасу и заменить дорожки к дому с гравийных на асфальтовые – потому что гравийные, как оказалось – хоть и позволили вписаться в бюджет – но не очень удобны в реальной жизни.
На самом деле техподдержка имеет вполне конечный объем обязательств. Оказывая такую услугу, разработчик МИС должен совершенствовать именно оговоренный и предусмотренный им состав обязательств. Наша задача, как исполнителя услуги техподдержки (и как разработчика МИС) – состоит в том, чтобы принимать и регистрировать обращения, стараться с каждым из них в приемлемые сроки и добросовестно разбираться. И если на техподдержку пришел именно вопрос и этот вопрос относится к тематике, по которой мы взяли обязательства – мы обязаны на него ответить. Если нам предложили что-то изменить в системе – мы обязаны это предложение зафиксировать. Если пользователь нашел ошибку в ПО – мы должны разобраться в этом и если мы подтверждаем, что это действительно наша ошибка – мы должны ее бесплатно устранить и передать Заказчику новую версию системы, уже без этой ошибки.
Оказывая техподдержку – мы не обязаны дорабатывать МИС под любое желание, мы не обязаны решать вопросы с обучением пользователя или администратора, мы не должны разъяснять положения приказов Минздрава или давать рекомендации по организации медицинской помощи. Мы не должны разбираться в инфраструктурных проблемах типа «У нас тут свет вырубили, Ваша несчастная МИС больше не работает. Кто у нас разработчик МИС? Вы! Ну вот и разбирайтесь с Вашей системой сами, раз вы ее так плохо написали». Да, признаюсь – мы можем это делать. Нередко мы это делаем. Нередко мы даже хотим это делать. Но не обязаны. Будет делаться та или иная просьба (хотя формулировки таких «просьб» иногда являются истеричными приказами – но оставим это на совести респондентов) – решает компания внутри себя на основе большого и сложного блока факторов.
Второй вопрос, который хотелось бы осветить - это «зачем нужна техподдержка?». Скажу сразу – как правило техподдержка – вещь сугубо добровольная. Заказчики вольны заказывать эту услугу или не заказывать. Для того, чтобы принять решение о продлении техподдержки – конечно же нужно понимание не только ее стоимости, но и ответа на вопрос – а зачем она вообще нужна? И вопрос этот далеко не искусственно придуманный – его реально задают и задают часто. Не Заказчики, но рядовые пользователи или даже пациенты. Задают вполне обоснованно и резонно – т.к. ситуация для тех, кто не посвящен в детали реализации информатизации лечебных учреждений на сегодняшний день, выглядит, как правило, примерно так: «В таком-то году – для примера – в 2011 г. – наш регион (или отдельная больница или поликлиника) купили вашу систему. Они (или мы) ее используем. Зачем нужно оплачивать какую-то техподдержку? Пусть используют ту МИС, которую купили – а ответы на вопросы получают из документации, которую разработчик обязан был предоставить.». Вопрос такой задает врач или медсестра на общих собраниях коллектива, при общении с нашими специалистами, когда они приезжают в ЛПУ, пишут в нашу службу техподдержки. Вопросы такие пишут пациенты в местные СМИ, которые потом с этим пытаются как-то разобраться. Как бы иногда нам (ИТ-специалистам) не казался странным этот вопрос – он реально задается и задается потому – что люди действительно не знают, зачем тратятся деньги?
Ответ на этот вопрос кроется в следующем. Во-первых, если у ИТ-специалистов ЛПУ будут возникать какие-то вопросы по системе, ее настройке или нюансах работы с какой-то функцией, с которыми они не смогли разобраться по имеющейся документации – они должны иметь возможность куда-то их задавать. Мы как коммерческая компания, не можем бесплатно содержать штат нужных для этого специалистов. Им, напомню, необходимо платить зарплату, налоги, отпускные, больничные и т.д. На бесплатной основе или за счет других проектов это делать недопустимо. Поэтому мы вынуждены брать деньги за такую работу.
Во-вторых - и это самое главное!!!! – на сегодняшний день разработка и внедрение МИС – это бесконечный процесс, требующий колоссальных усилий и имеющий огромную сложность. Об этом детальнее, пожалуй, напишу как-нибудь отдельно, а сейчас лишь констатирую – что на сегодня МИС – это не нечто законченное и обновляемое 1 раз в год типа Windows или офисного приложения. На сегодня, например, наша система – это большой и непростой программный продукт, включающий сотни различных отдельных программ и тысячи функций, выпуски обновлений которой мы просто вынуждены выпускать каждую неделю. Мы бы с радостью отказались от этого и выпускали новые версии системы пару-тройку раз в год, но реальность отечественного здравоохранения такова – что это совершенно неприемлемо для наших заказчиков. Объясню, почему:
1. Создание Единой государственной информационной системы здравоохранения (ЕГИСЗ). На сегодняшний день любая МИС, создаваемая и эксплуатируемая в государственных медицинских организациях – является важнейшим компонентом ЕГИСЗ. МИС не является неким автономным программным продуктом – это часть большой государственной системы. ЕГИСЗ находится в состоянии активного становления. В ней постоянно появляются новые сервисы или выпускаются усовершенствованные версии уже имеющихся компонентов. Сейчас – это «Федеральная электронная регистратура» и «Интегрированная электронная медицинская карта» 2-й очереди, до этого –федеральная НСИ или региональные учетные сервисы типа «Паспорта МО» или «Регистра медработников», завтра – это новые решения типа «Личного кабинета пациента» или других сервисов. Как любая сложная система, ЕГИСЗ требует постоянных доработок. Достаточно посмотреть на портал информационной поддержки ЕГИСЗ (http://egisz-docs.rosminzdrav.ru), чтобы увидеть – как часто там обновляются спецификации и нормативные документы, которые должны отслеживаться разработчиками МИС, на основании этих изменений должны вносится исправления в программный код МИС, должны выполняться доработки, тестирование, изменение документации и т.д. Обратим внимание, что Минздрав достаточно активно «продавливает» внедрение различных федеральных сервисов и требует выполнять жесткие сроки поддержки новых версий. И правильно, надо сказать, делает – иначе мы «калькулятор» Windows будет 5 лет внедрять и так толком и не внедрим – чего уж говорить о более сложных вещах. В этой ситуации – мы постоянно что-то доделываем или переделываем в МИС. Мы вынуждены постоянно выкладывать новые обновления системы, чтобы медицинские организации обновляли их у себя – и могли выполнить требования регулятора как по срокам, так и по составу интеграции своей МИС с федеральным центром.
2. Законодательное изменение в области здравоохранения. На сегодня система здравоохранения РФ находится в бесконечной модернизации. Постоянно меняются различные законодательные акты – от основополагающих (например, федеральный закон об охране здоровья) до конкретных приказов по различным специальностям (например, диспансеризация и профосмотры или новые учетные формы и журналы в трансфузиологии и т.д.). Для того, чтобы медицинская организация, использующая МИС, соответствовала требованиям приказов Минздрава – разработчики должны вносить необходимые изменения в систему, а соответственно медицинская организация – скачивать ее новые версии и обновлять свою инсталляцию.
3. Изменения в оплате медицинской помощи. Кроме модернизации непосредственно медицины, у нас в стране в последние годы очень сильные изменения идут и в области оплаты за оказанную медицинскую помощь и финансирование лечебных учреждений. В 2011 г. федеральный фонд ОМС издал приказ №79, который потребовал радикального переосмысления учета медицинской помощи в МИС. Потом выходили другие приказы и метод.рекомендации – уточнялся и пересматривался состав реестров на оплату медицинской помощи, изменялась нормативно-справочная информация. В последнее время идет внедрение новой формы оплаты – на основе клинико-статистических групп и т.д. и тому подобное. Все это опять же требует постоянных доработок и переработок различных внутренних механизмов внутри МИС. На сегодня – если медицинская организация не будет обновлять свою систему – она просто неспособна будет выставлять счета за выполненную работу и своевременно получать деньги на зарплату, свет, лекарства и т.д.
4. Предложения и замечания пользователей. В нашу компанию ежедневно приходят десятки самых различных предложений, замечаний, идей и т.д. от наших пользователей. Врачи и медсестры, пациенты, главрачи и начмеды, ИТ-администраторы – предлагают и просят что-то изменить, упростить, добавить новую возможность, новый документ, новый отчет и т.д. Мы, как разработчик, который искреннее стремится улучшить свой продукт, сделать его удобнее и полезнее – обязательно анализируем все эти предложения и там, где можем – делаем их. Система постоянно меняется на фоне такой работы. Где-то добавляются новые функции, где-то наоборот – какие-то ограничения или жесткие требования системы убираются или сокращаются. Вообщем, куча всего разрабатывается. Все это приводит к постоянному изменению как уже привычных пользователю кнопок или действий, так и появлению новых. Это, в свою очередь – вынуждает нас обновлять документацию. Разумеется, мы стараемся как можно быстрее предоставить все эти нововведения нашим пользователям – чтобы они получали их сразу, как только мы успели их сделать. Отсюда – и постоянные выпуски обновлений.
5. Исправления ошибок. Тут не надо таить греха и стыдливо обходить данный вопрос. Действительно, в системе находятся и устраняются ошибки. Они, также как и все изменения по описанным выше пунктам – тоже требуют как можно более оперативной доставки в медицинскую организацию. Но учитывая сказанное ранее – техподдержка – это не столько и, как минимум, не только получение МИС с исправлением ошибок. Это возможность получать и массу новых возможностей, процентный состав которых существенно выше, чем исправления ошибок.
Таким образом, на сегодня МИС – это постоянно изменяемый, живой организм. Задача разработчика – соответствовать реалиям времени и выпускать, как бы это не было тяжело – новые версии, постоянно совершенствуя продукт. Вынужденная задача Заказчика в этом случае – если конечно он на самом деле заинтересован в информатизации и улучшении ее эффективности, это постоянное обновление своей системы, помощь сотрудникам в освоении новых функций. Это требует возможность скачивать данные обновления и консультироваться у разработчика по возникающим вопросам. Поэтому техподдержка и требуется.
И последнее - о стоимости. Также достаточно острым вопросом является стоимость техподдержки. Имея на сегодняшний день одну из самых низких стоимостей этой услуги на рынке, мы тем не менее – периодически получаем такие вопросы, а иногда – и требования – сократить эту стоимость. На данный вопрос мы как правило терпеливо вынуждены разъяснять – что чем выше ожидания и запросы от тех.поддержки – тем больше специалистов должно быть задействовано внутри компании для оказания этой услуги. Если бы мы в ее рамках действительно только отвечали на вопросы, а разработку МИС вели бы спокойно, планово и выпускали новую систему пару раз в год, не делая там такого огромного количества доработок и изменений – то нагрузка на фонд зарплаты, налоги и затраты на работу офиса не были бы такими большими и это могло бы дать нам возможность оказывать тех. поддержку либо вообще бесплатно, либо за символическую сумму. Но на сегодня это абсолютно не так. Поэтому в стоимость техподдержки входит не только зарплата тех сотрудников, кто отвечает на звонки и электронную почту (как нередко воспринимают это наши Заказчики), но и зарплата программистов и тестировщиков, которые делают постоянные доработки для выпуска новых версий, затраты на консалтинг и аналитиков, работу других специалистов. И работа этих людей не разовая – а подчас – ежедневная. И большая часть этой работы, увы – как айсберг – не видна снаружи. Поэтому людям и кажется – что «взять девочку, посадить ее на телефон и пусть она отвечает на вопросы» - никак не может стоить те средства, которые запрашиваются за доступ к услуге техподдержки. Но как только каждую такую ситуацию начинаешь разбираться предметно – показывая заказчику, сколько изменений пришлось сделать по их заявкам, сколько вопросов пришло и сколько потребовалось времени на их разбор и ответы – то оказывается, что все действительно не совсем так, как казалось вначале. Вот только людей, готовых к такому анализу и вниканию в детали – увы, немного.
Весной этого года, готовясь к участию в Medsoft 2014, мы проанализировали большой объем данных по государственным закупкам в области информатизации здравоохранения. Доклад с результатами этого анализа был представлен в рамках программы конференции, презентация доступна здесь: http://www.kmis.ru/site.nsf/pages/medsoft2014_2.htm. Из этого доклада выделю и процитирую здесь раздел, касающийся стоимости техподдержки, которая сложилась в среднем по стране в настоящее время.
Средняя стоимость техсопровождения одной информационной системы в год на регион в 2013 г. составила 19,4 млн. руб. Средняя стоимость этой же услуги за весь региональный фрагмент в 2013 г. составила 26,9 млн. руб. То, что регфрагмент состоит как правило из нескольких систем, а сумма средней техподдержки каждой из них получается существенно выше, чем средняя стоимость за целиком региональный фрагмент, объясняется скорее всего эффектом масштабирования. Максимальная стоимость техподдержки, которую мы выявили в 2013 г., составил 349 млн. руб. - за сопровождение компонентов 1-й очереди ЕМИАС (г. Москва). Минимальная - 197 тыс. руб. в год за сопровождение одной региональной системы в МБУЗ «ЧЦГБ» (Пермский край). В целом, мы оцениваем, что на сегодня на рынке средняя стоимость техподдержки медицинской информационной системы для одной медицинской организации в год находится в пределах 200-350 тыс. руб. Стоимость эта существенно зависит как от количества МО в регионе и количества пользователей в этой МО, так и от конкретного бренда – той МИС, на которую техподдержка закупается. Средний срок контракта на техподдержку составляет 268,1 дней (более понятно будет сказать – что в среднем техподдержка закупается на 1 год). Максимальный срок, который мы выявили – составил 645 дней (один из сервисов ЕМИАС, г. Моска), минимальный - 34 дня (один из федеральных компонентов ЕГИСЗ)
В целом – здесь я постарался ответить на наиболее типичные вопросы, которые мы так или иначе получаем и разбираем в своей работе. Конечно, нет смысла тешить себя надеждой – что данное разъяснение будет всем без исключения подходить. Равно как и стоит оговориться, что, наверное, где-то нужно что-то улучшать или изменить в этом вопросе, проявляя гибкость и лояльность к нашим пользователям и заказчикам. Отмечу лишь, что на руководителях компании-разработчика МИС лежит огромная ответственность не только перед Заказчиком, состоящая в том – чтобы удовлетворять его потребности и исполнять взятые обязательства – но и перед своей компанией и своими сотрудниками, состоящая в том – чтобы обеспечить ожидаемую ими стабильность, уровень дохода, адекватности и разумности условий работы. А это – настоящее искусство на сегодняшний день. И как любое искусство – кому-то оно нравится, а кому-то – нет. И всем тут мил не будешь никогда.
P.S.: Коллеги! Важный комментарий, который упустил при публикации. В этом посте речь идет именно о техническом сопровождении МИС в мед.организации. Здесь я не рассматриваю то, как нужно выполнять проекты, как нужно делать внедрение, как создаются МИС или выполняются заказные разработки - это все другие грани работы современного разработчика МИС и там другие правила и отношение к обязательствам. Думаю, это важно оговорить было сразу - но пишу как дополнение.