IT-проекты самой быстрорастущей клиники России

Дмитрий рассказал: 

• Как работает IT-команда самой амбициозной сети клиник

• Какие внутренние IT-продукты есть в «Клинике Фомина»

• Кто такая Ася и как она помогает врачам в работе

• Есть ли смысл использовать готовые решения рынка или лучше делать все самим

• В каком приоритете реализовываются IT-проекты медицинского бизнеса

• Как оценить влияние цифровизации на выручку клиники 

• В чем заключается главная ошибка на старте цифровизации сегодня

• С чего начать цифровизацию при небольшом бюджете и как получить первые быстрые результаты

• Какие IT-специалисты нужны клинике в первую очередь, чтобы не тратить деньги зря

— Дмитрий Фомин в свежем интервью рассказал, что «Клиника Фомина» ежемесячно инвестирует 10 миллионов рублей в развитие своих IT-систем. При этом есть какая-то команда в штате и есть внешние подрядчики. Расскажи, пожалуйста, сколько у вас сейчас разработчиков именно в штате? 

– Если говорить просто про команду разработки, она у нас около 15 человек плюс-минус сейчас, смотря кого учитывать. У нас же есть и проджект-менеджер, и продукт-менеджер, и дизайнер, и аналитики, и тестировщики — так в сумме где-то будет человек 15. 

– Супер, а сколько у вас сейчас внутренних IT-продуктов и какие они? 

– Тоже интересный вопрос: что считать внутренними продуктами? Есть внешние подрядчики, но продукты получаются внутренние, потому что всё-таки они нам принадлежат. Я думаю, что можно тоже штук 10 перечислить, однако можно их подсистемами называть. 

У нас есть наши крупные базисные системы: медицинская информационная система на базе 1С, которая у нас построена. Она когда-то давно появилась и до сих пор развивается очень активно. И у нас есть вторая базисная система — это Ася. Про неё Дмитрий Фомин тоже много говорит. 

— А расскажи для тех, кто не слышал, хотя бы вкратце, какую работу она выполняет. 

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

У нас есть мобильные приложения пациента и мобильные приложения врача отдельные, есть несколько сайтов. Это опять же интересная история, потому что «Клиника Фомина» очень интенсивно развивается. И как-то это естественно происходит, это не то чтобы какое-то искусственное напряжение. Просто так получается, что есть необходимость бежать за этим быстрым развитием в плане айтишки. 

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

Конечно, мы сейчас стремимся к стандартизации, но бурный рост даёт свои плоды в том плане, что приходится где-то выбиваться из стандарта. Но мы всё равно стараемся всё это объединить в одну экосистему. 

Помимо этого у нас есть наработки по ИИ, некоторые являются прямо внешними для нас, то есть мы их используем. У нас есть и для проверки карт, и для УЗИ-снимков, и для эмбриологии. 

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

Эти подсистемы подключаются к Асе. Если у нас есть медицинские карты, почему бы их не внедрять? Это всё делается анонимно, ботами. В общем, такая идея. Тут, наверное, много можно говорить. Это разросшийся в экосистему IT-продукт. Это и хорошо, и плохо. Мы стараемся поддерживать это и развивать дальше. 

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

И при этом существуют разные подходы. Кто-то старается по максимуму все сервисы реализовать у себя внутри. Я встречал клиники, они у себя сами МИС написали, Calltouch заменили на какую-то свою внутреннюю систему складной аналитики — такой подход. А кто-то, наоборот, по максимуму использует уже готовые реализованные внешние сервисы, которые не нужно разрабатывать, а внутри разрабатывает только то, что внешние сервисы не решают. И это как бы две крайности. 

Как вы у себя в команде находите баланс между этими подходами? Взять готовые модули, а чего нет готового на рынке, самим написать? Или же нет, нам нужно всё только своё, проприетарное какое-то, внутреннее? 

— Слушай, если отвечать в общем на этот вопрос, пока нет понимания, что дальше. Это зависит от амбиций, от стратегического какого-то видения на несколько лет вперёд. 

Но если есть здесь и сейчас, мы небольшая компания, небольшая клиника, которой хочется уже что-то цифровизировать… Я думаю, нельзя сейчас просто взять и на бумажках до сих пор писать. Уже так или иначе какая-то цифровизация есть, даже если это google-таблица. Из неё уже можно построить аналитику и что-то интересное, пошарить доступ и аккаунты сделать — в общем, много чего можно. 

Вопрос о том, коробка / не коробка, зависит от того, насколько вы действительно крупные, уникальные и амбициозные. Есть ли у вас понимание, что через какое-то N время вы будете крупными и уникальными? Конечно, крупная уникальность — это кастомная разработка, это разработка под себя. 

Своими / не своими силами — это отдельный вопрос. Можно найти подрядчиков хороших, отдать на аутсорс, они всё сделают. Но коробочные решения, как обычно, хороши до тех пор, пока они подходят в их моментах кастомизации. Всё равно коробочное решение каждое имеет кастомизацию. 

Очевидно, что мой ответ строится вокруг слова «амбициозность». У меня лично в голове всё в это упирается. Если вы амбициозные, если вам надо расти-расти, как «Клиника Фомина» сейчас действует, то без своего продукта не обойтись. 

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

Мой ответ на вопрос «как находить баланс?» — надо смотреть на кастомность ваших идей и что дальше будет с ними, хотите ли вы действительно потом на основе этого что-то своё интересное делать. 

Мы достаточно инновационные ребята. Дмитрий Фомин часто употребляет это слово. Он говорит: «Мы имеем право быть инноваторами, поэтому почему бы и нет?» А чтобы быть инноваторами, нужно, собственно, это всё провернуть в своих знаниях, в своих компетенциях, в своей специфичности. 

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

Если это обособленный продукт, мы понимаем, что это продукт, который способен жить отдельной жизнью. Теоретически его можно выделить, как кусочек, вырезать, поставить не то, что в другую МИС или в другую Асю, а просто отдельно поставить и он будет жить. И тогда этот кусочек мы очень спокойно можем каким-то подрядчикам отдать. Или найти на стороне решение, создать какой-то коммуникационный шлюз, общение с Telegram, WhatsApp, почтой. Зачем нам самим разрабатывать? 

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

В общем, тут мы стараемся делать всё сами, за исключением вещей, которые можно выделить в отдельный кусок. 

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

— Так везде. Это вопрос не клиники, это вопрос человеческого подхода, так как всегда хочется сейчас, и всё, и сразу. 

У нас интересная схема сейчас образовалась. Несмотря на то, что команда одна, мы внутри поделились на подкоманды. 

Начнем с того, что у нас есть направления: 1С, Ася, которая веб-приложение в браузере, и мобильные приложения. У нас уже три направления такие просто технические. Помимо этого у нас есть направление бизнес-заказчиков. У нас они делятся на мед.департамент, коммерческий департамент, департамент заботы или сервиса. У нас есть разные департаменты и разные ребята объединены в разные кучки. В рамках этих 15 человек появляется где-то 6-7 полусамодостаточных юнитов, которые умеют с этим работать. 

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

Особенно сейчас ситуация в «Клинике Фомина», опять же с этим ростом связана, с тем, что нужно поспевать за ним, нужно оптимизировать процессы. 

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

У нас есть такая система, как помощник принятия решения. Это история, которая в Асе подсказывает врачу: если он понимает, какой диагноз, она подсказывает, какое лечение рекомендовано, опрувлено всеми экспертами и всё такое. Его же нужно поддержать в каком-то актуальном состоянии. 

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

Можно google-таблички взять. Они у нас, естественно, в какой-то момент были, только на них и жили. Но все равно это человеческий фактор. Чем больше мы разрастаемся, тем сложнее поддерживать это в актуальном состоянии, добавлять и нигде не забывать. Если врач у нас в клинику пришёл, нужно не забыть, чтобы он появился в мобильном приложении, на сайте, в системах учёта, в Асе, в МИСе. В общем, там только аккаунты создавать очень долго. Это тоже некие бизнес-процессы, которые мы можем оптимизировать. 

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

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

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

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

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

Но если в плане денежного потока какого-то, если мы говорим про клинику, как бизнес, без определённой разработки просто на фоне конкурентов мы вообще не очень будем выглядеть. 

Тот же сайт. Если нет сайта, вроде как понятно, что очень странно дальше жить. Если мы чуть-чуть разрастаемся, нам нужен колл-центр. Колл-центр тоже подразумевает под собой всё-таки цифровизацию, если в таком широком плане. Очень сложно построить колл-центр на одном телефоне, который вы купили с сим-картой в магазине. 

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

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

Всё остальное — оно очень сложное. Мне кажется, расчёты очень сложные и должны учитывать действительно много всего, как в квантовой физике. 

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

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

— Большинство клиник, кто нас будет смотреть, не обладает бюджетным уровнем «Клиники Фомина» просто по распределению статистическому. Они только присматриваются к цифровизации. Что бы ты им посоветовал? С чего им начать, чтобы увеличить вероятность успешного входа в IT? Для клиник, у которых еще нет внутренней IT-компетенции. С чего начать, чтобы не вложить 10 миллионов рублей в МИС, которая просто разговоры и ничего не происходило. Может быть сразу IT-директора или тимлида, или интегратора, или консультанта привлечь? Куда им идти и что делать? 

— Давай я это слово опять скажу, амбициозность. Если мы сейчас уже понимаем, что мы хотим быть с 50 филиалами, например, хотя бы, то, безусловно, уже сейчас, чем раньше, тем лучше, нужно задуматься о грамотном построение какого-то ядра. У нас это называется ядро техническое, core-часть какая-то. Ядро, вокруг которого всё остальное будет строиться. МИС является ядром, на самом деле. 

Конечно, заказать себе МИС, что-то сделать и потом не понимать, что с ним делать дальше — это очень печальная история, потому что всё остальное будет на основе него. 

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

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

— Смотри, если бы мы были сейчас 10 лет назад, то я бы ответил совсем по-другому. Но на текущий момент мне кажется, что важно не сочинить что-то самим в базовых вещах, которые уже стандартизированы на уровне государства и на уровне всего мира. 

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

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

В самом начале пути не нужно быть инноваторами в этом плане, нет никакой необходимости. Нужно построить хорошее качественное ядро, а потом делать инновации сверху. 

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

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

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

Если вы чувствуете, что у вас пока не время своей собственной команды, то при работе с подрядчиками, конечно, нужно максимально запрашивать документации. Документации к механике, как минимум, как это работает, почему и зачем, чтобы потом можно было это как-то поддержать, расширять, обновлять и так далее. 

Если это внутренняя команда, то нужно всегда следить за нашим дорогим любимым бас фактором, чтобы не получилось так, что команда была, сплыла и как бы больше ничего нет. Если есть сомнения в текущей команде, то мы ведём с ними себя как с подрядчиками. Говорим, что нам нужно везде вики, какое-то описание. Оно и так должно быть, мы особо требовательны должны быть к этому. А если доверие к команде хорошее и мы понимаем, что за айтишкой в том числе и наше будущее, то просто тут важный момент следить за бас фактором. Нельзя оставлять в одних руках все знания продукта. 

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

Что бы ты рекомендовал? Я слышал, что многие берут МИС и на её базе что-то уже строят своё, свой замок, космолёт. А кто-то говорит: «Нет, нам нужно полностью с нулевой какой-то базовой архитектуры начать, самим всё строить, совсем кастомное». 

— МИС 1С — коробочная, ее потом в принципе можно дописывать. В этом вся прелесть, за это её любят и используют. Там действительно есть всё для начала работы, некий такой кит, наборчик. Ты взял, водичкой залил — и готово, и пользуешься. Просто добавь воды. У тебя уже понятно, где проводить денежки, где хранятся пациенты, куда сохранять услуги и т. д. 

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

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

1С, если мы говорим о каком-то глобальном росте, не выдержит больших нагрузок. Хотя последние версии 1С уже скорее всего могут это делать. Но если мы говорим о высоконагруженных, о какой-нибудь архитектуре, которая начинает реплицироваться, несколько инстансов, одного и того же — с 1С будет сложно жить, если на перспективу. Но это довольно далёкая перспектива. И как всегда, если делать всё грамотно, записывать, что, зачем, почему так работает, вообще почему мы так решили… 

Частая история, что кто-то специально это сделал, мы уже 2 года так работаем, но никто не понимает, почему и зачем. Говорят: «Измените». И тут всегда встаёт вопрос: если кто-то это сделал 2 года назад, не поломает ли это что-то, если это мы сейчас изменим? И из-за того, что нет этих знаний, потом сложно вносить изменения. 

Если у меня ничего нет, я бы взял 1С, на самом деле, как старт и дописывал его. Но если у меня есть амбиции, я хочу уже, и сейчас нет ресурсов ждать разработку, нужно выделить хотя бы 3-6, лучше 9 месяцев на написание своей МИС, в которой всё будет реально нормально, то лучше взять 1С. Если есть деньги, можно запустить параллельно процессы. Пошёл в 1С и ждёшь, пока идет разработка. Но если нет, берёшь просто 1С. 

За доработками надо немножко следить, что там происходит, зачем мы это делаем. Вопрос «зачем» — он всегда корневой. Что за правила в этом кроются? Какая потребность? Если мы это всё знаем, в какой-то момент, даже если мы увидим, что нам хочется отказаться от 1С или любого другого коробочного решения, то мы сможем это сделать. Потому что будем понимать, что, зачем, почему работает. 

Честно говоря, это немножко утопичная история. Я это говорю, как правило хорошего тона и всё такое. Но очень редко это случается в таком идеальном формате, что потом очень легко всё восстановить, понять и перенести на другие рельсы, просто потому что это человеческий фактор, это команда, люди, сроки и так далее. Но мы можем к этому стремиться, мы можем об этом помнить. Если этому внимание уделять, то в конце концов мы не останемся у разбитого корыта. Да, будет сложно всё равно перейти, это всё равно будет требовать времени и денег, но это не будет невозможным, это не будет каким-то провалом. 

— Вы точно амбициозные и инновационные, сейчас у вас продукт на базе 1С, а вы уже параллельно пилите новую МИС, которая без 1С, для того, чтобы более высокие нагрузки выдерживать? 

— Если говорить про нашу слоистость IT-инфраструктуры, то сейчас для нас есть некое ядро. Привожу пример, государственные банки Америки. У них же тоже цифровизация будь здоров. Но их core-часть, их ядро, написано 70 лет назад. И оно на тех видах процессоров, которые больше не выпускают. И оно до сих пор работает именно на этом. Мы не обязаны даже переписывать, честно говоря. Если у нас есть какое-то ядро, и оно работает, нам сложно находить программистов будет в какой-то момент. 

Благо 1С развивается и программисты тоже вместе с ним развиваются. У нас не такая же система, как у американских банков, которые ищут семидесятилетних стариков, чтобы хоть что-то вообще поправить в этом ядре. У нас такой проблемы нет. 

Слои сейчас такие, что у нас есть 1С, и она за многие-многие вещи отвечает. Мы же ещё знаем, что у нас есть бухгалтерия, ещё что-то, тоже на базе 1С, поэтому там интересная интеграция. 

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

И есть какие-то слои, которые мы можем сейчас отделить. Они раньше были в 1С, мы отделяем. 

А те слои, которые ещё не успели попасть в 1С, мы уже думаем, как туда не заводить вообще. Опять же, если говорить про кадры, про ресурсы человека, часы и всё такое, то найти хорошего грамотного 1С-специалиста немножко сложнее, чем, например, хорошего грамотного python-разработчика. Просто рынок другой. И поэтому, чисто на мой взгляд, как будто бы просто прагматичнее с 1С нагрузку убирать, особенно когда у нас нагрузки всё больше и больше, интеграций всё больше, больше желаний. 

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

А 1С оставляется, естественно оно никуда не уходит, оно будет жить как ядро системы. Оно будет дорабатываться, оно будет развиваться, потому что дальше там есть ещё и бухгалтерия, и всякие аналитики, которые сводятся в МИСе, и касса работает через 1С. 

В общем, у нас так получилось. У нас это ядро, как в банковской системе, которое нельзя выкинуть. Оно настолько важное, настолько фундаментальное, что будет неправильно. 

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

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

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

Что проще и быстрее реализовать? Мне кажется, это надо смотреть на месте. Конечно, начинается всегда с сайта, потом по расширению. Уже дальше у нас идут необходимости. Без каких-то вещей мы просто не конкурентоспособны. 

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

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

Если говорить про 10 лет назад, я тогда тоже писал МИС. Тогда это были совсем другие инструменты, совсем другие понимания, что такое МИС. По большому счёту, тогда всё складывалось из того, что очень много бумажек и как бы работать с ними не очень удобно. Давайте просто, как есть оно, перенесём, и будет тоже самое, только в цифре. На компьютере будут вбивать врачи то, что писали раньше руками. 

Сейчас мы уже прошли этот период, как человечество, наверное. Мне кажется, уже мало кто так делает. У всех стоит компьютер так или иначе, даже если это не IT-система. Есть Word или что-то типа того. 

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

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

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

— Может есть какой-то запрос к нашей аудитории? Может кого-то сейчас ищете в команду, или какого-то подрядчика, или какую-то коллаборацию — что угодно? 

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

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

В остальном, вроде не могу сейчас даже сказать. Я думал, может быть, ты что-то посоветуешь или кто-то увидит, что происходит, просто придёт и предложит помощь. 

— Тогда мы оставим просто под видео какой-то твой контакт, куда можно будет написать по поводу либо 1С-специалистов или просто что-то предложить. Спасибо большое, Дмитрий. Очень интересно и здорово, что получилось достаточно человеческим языком объяснить то, что происходит в разработке. Мне кажется, это будет очень полезно нашим зрителям. 

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

 Я просто ворвусь к тебе, в твою программу, потому что всё-таки IT-мир — это отдельный мир, я так считаю. Я в нем живу, я его вижу. Это абсолютно отдельный мир со своими правилами, законами, как работают команды. Ты спрашивал про подходы, ты спрашивал про подрядчиков, про то, как написать МИС, не потратив деньги впустую. Это прям отдельный мир, о котором нужно рассказывать, в который нужно погружаться. Поэтому я как раз посоветовал, что в момент, когда хочется начать, важно найти человека, который в этом уже что-то понимает. Может быть не супер профессионала дорогостоящего, но хотя бы связанного с этой областью, иначе можно очень легко заблудиться.