1С

На данный момент большинство банков работают преимущественно на зарубежных решениях. Перейти на российское ПО – задача непростая, но рано или поздно ее придется решать. Минимизировать возникающие проблемы призвано отраслевое решение на платформе «1С», разработанное IAS Digital. Татьяна Мошкина, управляющий партнер IAS Digital и номинант на премию Data Award, рассказывает о предпосылках создания системы и ее первых шагах на рынке.

- Каковы сейчас потребности банков? Какие у них головные боли?

Основной вызов в банках в 2022 году – это импортозамещение и переход на отечественный софт. Не секрет, что до недавнего времени базы данных и программное обеспечение банков были основаны на иностранных платформах, вендоры которых перестали оказывать поддержку российским компаниям в прошлом году. В программы цифровизации в банках начали включать задачи по поиску и внедрению отечественных аналогов банковских решений. Если посмотреть на российскую специфику, то банки ушли далеко вперед относительно других отраслей по части цифровизации: это решения по роботизации бизнес-процессов, технологии Process Mining, технологии умного клиентского сервиса в виде мессенджеров, чат-ботов, диалоговых интерфейсов, цифровых помощников. Клиентоцентричность банковских команд – главный приоритет, это и позволяет им быстро выводить новые продукты на рынок.

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

- Что собой представляет созданное вами решение?

Это автоматизированная банковская система на платформе «1С». Для банковской отрасли эта платформа не так популярна – в основном банки если и использовали «1С», то для учета административно-хозяйственной деятельности. Мы же автоматизировали основные операции банка, то есть банковский день.

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

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

- Что подвигло вас на создание системы?

После ухода SAP и Oracle из России и подписания указа, запрещающего использовать зарубежный софт в критической инфраструктуре, многие российские банки и другие компании финансового сектора оказались в невыгодном положении. Перейти на российское ПО быстро и недорого – задача для банков неординарная. По подсчетам аналитиков, 50% ERP-систем в России функционируют именно благодаря решениям SAP. Пока перспектив окончания санкционной войны нет, и альтернатив у финансового сектора не очень много. Банки могут использовать разные российские решения, но комплексных автоматизированных платформ, основанных на «1С», на рынке нет.

На данный момент большинство банковских систем работают преимущественно на импортном программном обеспечении. В частности, СУБД Oracle используют 80% банков, а PostgreSQL – 10%. Поэтому переход на отечественные аналоги для банков будет неизбежен, при этом банки будут сталкиваться с определенным количеством проблем, связанных с другой архитектурой, а следовательно – с иной логикой работы. Условия рыночной конкуренции выдвигают на первый план задачу использования современных отечественных технологий – с прогнозируемой стоимостью, технической поддержкой и наличием большого количества специалистов, способных провести миграцию и заниматься развитием решения.

- Какие задачи решал проект?

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

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

- Какие принципы соблюдались при создании решения?

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

При этом мы понимали, что банковская отрасль регулируется Банком России, и коммерческий банк не может остановить свою деятельность для внедрения нового программного продукта. Даже часы простоя чреваты существенными убытками и потерей клиентов. Мы создавали решение таким образом, чтобы в дальнейшем можно было поэтапно интегрировать различные модули системы «АБС: Учет и управление в банках» в текущий контур автоматизации, не нарушая при этом основную работу банка.

Процесс разработки решения шел по методологии Agile стримами по одной-двум неделям совместно с представителями бизнес-подразделений, включая понедельное планирование всех процессов. Внедрение происходило помодульно. Команда проекта состояла из 1-2 специалистов со стороны банка по определенному функциональному блоку и 4-5 со стороны разработчика в разные этапы разработки и тестирования.

- Сколько времени и ресурсов потребовалось на реализацию проекта?

Мы начали разработку АБС пять лет назад, но не с нуля. У IAS Digital к этому моменту уже был богатый опыт автоматизации деятельности некредитных финансовых организаций – профессиональных участников рынка ценных бумаг, страховых компаний, негосударственных пенсионных фондов. На основе одного из решений, которое выпустили в еще 2017 году совместно с «1С», мы начали разработку автоматизированной банковской платформы. Тогда же у нас появился первый клиент, для которого и была реализована АБС, – «Первоуральскбанк».

- Как насчет имиджевых барьеров? Все-таки в понимании подавляющего большинства специалистов «1С» — это не про банки.

Так было до недавнего времени. Сейчас вообще происходит много необычного. Банки, наверное, – единственная отрасль, которая до прошлого года довольно редко использовала решения «1С».

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

- Работа банков неразрывно связана с анализом данных: анализ рисков, клиентская аналитика, подготовка маркетинговых кампаний и т.п. Какими средствами предполагается поддерживать эту работу?

В «1С» есть специализированное решение «1С:Аналитика», которое позволяет реализовать аналитику любой компании в виде дашбордов, графиков, отчетов. Кроме того, есть решение «1С:Маркетинг», которое не специализировано для банков, но зато широко используется на рынке. Основные затраты банка обычно связаны с внедрением, доработкой и сопровождением АБС, а остальные решения всегда можно интегрировать с основной системой. Решения на общей платформе позволяют разработать единый интерфейс, и тогда пользователь будет работать в системе без необходимости переключаться между разными приложениями, то есть с использованием бесшовной интеграции. Сама АБС встраивается в ИТ-инфраструктуру любого банка, текущие интеграции с другими программами всегда можно будет поддержать.

- Какие результаты достигнуты и ожидаются?

Первым клиентом стал «Первоуральскбанк» – небольшой коммерческий банк из города, который находится в Свердловской области на границе Европы и Азии и имеет население в 114 тыс. человек. Банк получил самую современную систему управления предприятием с банковским модулем и возможностью создавать большое количество управленческих отчетов с каскадированием данных. В решении автоматизирован расчет нормативов банка и составления отчетности для Банка России и ИФНС.

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

На текущий момент решение внедрено и успешно работает в нескольких региональных банках.

- Насколько это востребовано рынком?

Рабочие встречи с представителями банков в 2022 году показали, что многие банки хотят уйти от банковских автоматизированных систем, основанных на зарубежных разработках и использующих импортные СУБД. Они заинтересованы перейти на российское программное решение, которое бы обеспечило возможность ведения основных операций и одновременно ведение бухгалтерского и управленческого учета, а также удешевило бы стоимость сопровождения и владения банковским ПО. Таким образом, выявлена потребность рынка в комплексной автоматизации бизнес-процессов на базе единого решения, включая учет кредитов, депозитов, факторинговых и лизинговых операций с возможностью гибкого моделирования. Наше решение содержит функционал для управления продажами и банковскими сделками, казначейства и бюджетирования, а также формирования оперативной, управленческой и бухгалтерской отчетности в соответствии с требованиями Банка России.

- Что вы со своей стороны делаете для того, чтобы банки, использующие ваше решение, становились data-driven?

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

- В чем роль проекта для развития рынка?

Кейс внедрения автоматизированной банковской системы на платформе «1С» показал, что она может активно внедряться в рамках импортозамещения в российских банках, помогая экономике справиться с последствиями кризиса, а миллионам людей получать современные банковские услуги. Автоматизированная банковская платформа – сложная разработка, на которую долгие годы на рынке никто не мог замахнуться. Тем не менее мы разработали решение. В итоге банки получают экономию финансовых затрат и независимость от иностранных вендоров.

- А каковы перспективы с финансовой точки зрения?

Вызовы 2022 года помогли нам вывести на рынок продукт, который в перспективе может захватить большую долю рынка. Рыночный сегмент внедрения – 327 банков, емкость рынка – 832,5 млн руб.

В целом же рынок ИТ-решений для российских банков составляет 514 млрд руб., а правительство планирует субсидировать переход банков на российское ПО. Это создает для нас потенциал роста и выхода практически в «голубой океан».

- В каком направлении будет развиваться платформа?

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

С вождем (официальная должность) «Кнопки» Андреем Завьяловым мы встретились в интересное время. Компания, специализирующаяся на аутсорсинге бухгалтерских и юридических сервисов, готовится к выходу на новый для себя рынок продажи технологий. Хороший повод поговорить об автоматизации, применимости и масштабируемости облачного аутсорсинга, состоянии рынка бухуслуг и о том, что будет, если посадить на одном этаже офисного здания тысячу бухгалтеров.

Если попробовать описать одной фразой, «“Кнопка” — это…»?

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

Бэк-офис для бэк-офиса?

Бэк-офис для другой аутсорсинговой компании.

Применима ли эта модель для других видов процессов — например, для оптимизации закупок, для ИТ, может быть, для чего-то еще?

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

Андрей Завьялов, сооснователь «Кнопки» В 2013 году стал сооснователем «Кнопки». До этого пять лет проработал в крупной энергетической компании в должности финансового и генерального директора. Три года управлял инвестиционной компанией в сфере «зеленой » энергетики. Сменил привычную сферу, отказался от важных должностей и три года руководил продажами интернет-проектов «Эльба» и «Диадок» в СКБ «Контур». Заработал лысину, степень MBA и огромный опыт в b2c- и b2b-продажах. Начал свой длинный профессиональный путь с работы на железной дороге: был самым молодым начальником поезда (командиром подвижного состава).

Если говорить не про ИТ, а про бизнес-модель, кроме бухгалтерии, есть еще какие-то процессы, стоящие в очереди на аутсорсинг?

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

Существуют ли в России и мире компании, которые реализуют бизнес-модель «Кнопки» и про которые вы можете сказать, что вы с ними прямые конкуренты?

В России основные игроки на этом рынке — это, как ни странно, банки. Они идут в предпринимательский low-сегмент. Появляется новая категория клиентов — самозанятые, которые будут платить 4%. Это несколько десятков миллионов человек. Банки хотят оказывать им услуги по ведению налогового учета. ИП и малым предприятиям, которые платят 6%, они предлагают налоговый и бухгалтерский учет. Наше поле — устоявшийся, стабильный бизнес, у которого уже есть сотрудники. Этим компаниям мы предлагаем облачный бэк-офис.

Такого в мире больше нет. Облачные CRM, 1C-Bitrix — они решают узкие задачи. Мы решаем широкую задачу: закрываем бухгалтерские и юридические вопросы сопровождения бизнеса. Разница огромная. В отличие от CRM, здесь высокая ответственность, штрафы, регламенты. Никто не выставит бизнесу штраф за неверное использование CRM, но, если бухгалтер не сдал какую-то отчетность, заблокируют счета в банках.

Воспроизвести вашу бизнес-модель никто не захотел, не догадался или не смог?

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

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

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

Сколько сейчас клиентов у «Кнопки»? Какие планы роста?

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

Из-за проблем с масштабированием бизнеса?

Благодаря тому, что мы создали методики бухгалтерского и юридического сопровождения, мы можем масштабироваться без особого увеличения штата. После ошибок это была вторая причина придумать технологии автоматизации. Мы просчитали бизнес-модель и поняли, что можем нанять хоть тысячу бухгалтеров. Даже при таких объемах модель будет работать и приносить прибыль. Но тысяча бухгалтеров? Это зомби-апокалипсис! Поэтому мы стали думать, как, не увеличивая количества сотрудников, обслуживать больше клиентов. Еще один путь — самим использовать аутсорсинг. За счет того, что мы очень хорошо знаем бухпроцесс, мы знаем каждый кирпичик и умеем некоторые из этих кирпичиков отдавать на аутсорс. Это тоже позволяет хорошо масштабироваться.

Насколько далеко зашла автоматизация? Момент, когда не останется ни одного бухгалтера, а будет несколько инженеров, которые обслуживают серверы, уже появился на горизонте?

Быстро это не произойдет. Существуют ФНС, Росстат и Пенсионный фонд: государственные структуры не будут с разговаривать с бизнесом электронно. Конечно, электронный документооборот появляется. Лидер в этом отношении — налоговая инспекция: в девяти случаях из десяти с ними можно решить вопросы дистанционно. Но остаются 10%, которые пока не решаются. Пенсионный фонд требует личного присутствия. Если возникает проблема, ее можно решить только голосом. Пока структурированного общения с госорганами не получается, перед нами стоит одна из самых сложных инженерных задач — перевод неструктурированной информации в структурированную.

Какие метрики вы используете, как измеряете эффективность своей работы?

Мы фанатики метрик — измеряем вообще все. Мы начали с исследования структуры работы бухгалтера. Мы стали замерять его рабочий процесс, иногда буквально секундомером. Стало понятно, что надо на каждый процесс закладывать отдельную метрику. Сколько документов заведено, сколько не заведено, каким клиентам робот отправил расчет налогов, каким нет, скорость ответа: 90% ответили за час, 100% ответили за 18 часов, 50% ответов уложились в 15 минут. Вся «Кнопка» построена на метриках. Это наш фетиш.

Какие из них ключевые? Если тебе надо за минуту понять, хорошо ли работает какое-то подразделение, на что ты смотришь?

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

Какие платформы для коллективной работы вы используете?

«1С». Мы используем ее как ядро. «1С» обладает лучшей компетенцией актуализации форм отчетов перед государством. Как только государство меняет внешний вид налоговой декларации, это делает «1С». Это первый и базовый инструмент, как и у всех бухгалтеров России. У нас есть Slack. Это важный коммуникационный инструмент внутри компании. Мы используем Jira и собственное мобильное приложение.

Основной инструмент коммуникаций с клиентом — чат?

Да. Чат, который мы самостоятельно написали.

Клиент пишет в чат, что ему надо что-то сделать, и ваши ребята садятся и делают?

Да.

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

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

Чем меньше клиент думает о бухгалтерии, чем меньше он ее видит, чем меньше он вообще о ней задумывается — тем лучше. Поэтому чат интереснее.

Идеальный способ коммуникации — аналог игры «Веселая ферма». Ты включил приложение, у тебя моргает: сюда отправь пару сканов документов, потому что их требует бухгалтер, здесь мигает запрос по увольнению или приему сотрудника, тут тебе загрузили платежки в банк, зайди их подпиши. Это не совсем чат. Чат тоже есть — когда возникают вопросы, которые надо обсудить. Но в целом все сводится к графическому пользовательскому интерфейсу.

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

«Кнопка» — это стартап?

Скорее нет, чем да. Что такое «стартап»? Компания, которая что-то новое придумывает? Да. Убыточная? Да. Прибыльная? Да. И на те же вопросы можно ответить «нет».

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

Сколько времени прошло с создания «Кнопки» до выхода на оперативную безубыточность?

Три с половиной, даже четыре года.

Называли цифру 10 млн долл. инвестиций в «Кнопку». Это похоже на правду?

Да. Хотя смотря по какому курсу. По нынешнему — меньше. Но порядок такой.

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

Есть мнение, что все бухгалтерские сервисы в России собирают крошки со стола «1С». Это так?

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

Но что считать рынком бухуслуг? Если посчитать, сколько платит РЖД своей дочерней компании, которая ведет их бухгалтерию, тогда «1С» — просто один из игроков на этом рынке. Если мы отбрасываем крупные компании и банки, это будет другой разрез.

Если брать сегмент мелких компаний, самозанятых и ИП и убрать верхний слой, где работают зарубежные системы, то на «1С» придется 99% софта, которым пользуются для бухучета. Но они же зарабатывают на лицензиях. А рынок бухуслуг гораздо шире. В том же РЖД работают 8 тыс. бухгалтеров, приплюсуем сюда еще какой-нибудь Магнитогорский металлургический комбинат. Бухуслуги гораздо дороже софта внутри. Поэтому, кто у кого подбирает крошки со стола, не знаю.

Ты знаешь, что происходит с малым и средним бизнесом? Расскажи об этом. Как меняется бизнес твоих клиентов?

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

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

Этой тенденции уже три тысячи лет…

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

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

Исчезла тема «рисования» документов. Раньше регулярно спрашивали, можем ли мы это сделать. Сейчас этот вопрос даже перестали задавать.

Второй по популярности вопрос был: «Ведете ли вы черную кассу?» Потому что бухгалтер обычно ведет черную кассу. Сейчас такого понятия практически нет. Или совсем нелегальный кеш, или все уже законно. Эта разница стала очень явной: «черное» стало совсем черным, а «белых» стало больше.

Блиц, короткие вопросы, на которые ты можешь отвечать не обязательно коротко. Хороший формат, не я придумал. Agile работает?

Да. Прямо большими буквами — ДА.

Выход на биржу или продажа стратегам?

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

Если ты застрянешь в лифте с Нуралиевым, о чем ты с ним поговоришь?

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

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

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

Для чего больнице ERP?

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

В журнале ERP Solutions Review выделяются две наиболее распространенные цели внедрения медицинской ERP-системы. Во-первых, создание длительно хранимой интегрированной базы данных, куда в режиме реального времени поступают сведения о состоянии здоровья пациентов (electronic health record, EHR — электронной медицинской карты, ЭМК). Ведя медкарты в безбумажном виде, медицинская организация получает возможность оперативно формировать статистические и управленческие отчеты.

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

Как устроен крупнейший рынок медицинских систем

Благодаря государственному субсидированию внедрения EHR, США являются одним из мировых лидеров в этой области. К середине 2017 года в программе внедрения EHR приняли участие почти 7,8 тыс. больниц. Примерно половина из них используют решение одного из десяти самых популярных на рынке разработчиков. Каждый из тройки крупнейших вендоров: Epic Systems, Cerner и Meditech — охватывает почти по 1 тыс. клиник. Уточним: Epic — разработчик автономной EHR-системы, а Cerner и Meditech — производители медицинских ERP-систем со встроенными EHR-модулями. Более чем в 1,2 тыс. госпиталей для ветеранов Министерства обороны США используется разработанная этим ведомством система VistA, которая является одновременно ERP- и EHR-системой. Активно действуют на медицинском рынке и поставщики классических ERP-решений: Microsoft, Oracle и SAP.

Лидеры среди ERP и EHR — платформенные системы, созданные в конце 1970-х — начале 1990-х годов. В случае построения ERP- и EHR-систем на разных платформах, как со стороны ERP, так и со стороны EHR задействуются интеграционные механизмы. Чаще всего они основаны на отраслевом стандарте — протоколах организации HL7.

Примером такого симбиоза двух платформ для создания медицинской ERP-системы служат Oracle и Epic: интеграция организована как на технологическом уровне (Oracle Health Management Platform), так и на бизнес-уровне. Многие партнеры Epic являются одновременно и партнерами Oracle, что позволяет им оказывать услуги по созданию медицинской ERP с EHR-модулем.

Следующая по распространенности коммерческая EHR-система — Cerner i.s.h.med, а также лидер среди свободно распространяемого программного обеспечения — VistA используют другой подход: создают единую систему на одной технологической платформе, где есть функции как ERP, так и EHR. Преимущества такого подхода: система имеет единый интерфейс, использует единую базу данных и единую среду разработки, интеграционных швов в ней нет.

Почему выигрывают платформы

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

В технологических платформах имеется CASE-средство разработки, которое дает возможность создавать программы путем манипулирования графическими объектами вместо написания текста. Технологические платформы имеют собственные языки программирования 4-го поколения. Это высокоуровневые предметно-ориентированные языки, пригодные для визуального программирования, то есть программирования с помощью формирования различных схем.

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

Индустриальный подход и партнерская модель

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

Это позволяет применять принципы разделения труда и индустриальный подход к разработке прикладных решений (см. рис. 1).

Платформа разрабатывается вне зависимости от отрасли и включает передовые технологии и стандарты. Центральные прикладные решения (CRM, ERP и др.) с открытым кодом бизнес-логики разрабатывает вендор. Отраслевую специфику в решение вносят партнерские компании, а специфику конкретного предприятия — партнер или ИТ-служба клиента. Заказчик получает решение с открытым кодом бизнес-логики, которое может сопровождать любая партнерская компания или его собственная ИТ-служба.

Рис. 1. Поддержка партнерской бизнес-модели платформами

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

Каждому — по отдельной «квартире»

Все упомянутые выше поставщики платформенных медицинских ERP (Cerner, Epic, Microsoft, Oracle, SAP и VistA) предлагают два варианта использования своих ключевых продуктов: установку на локальном оборудовании клиента и подключение к облачному сервису по модели «программное обеспечение как услуга» (SaaS).

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

В облачном приложении данные хранятся в ЦОДе в общей для всех медицинских организаций БД в режиме разделения данных. Каждой медицинской организации выделяется собственная область в базе данных, причем эти области изолированы.

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

Цель облачных приложений — снизить расходы на поддержание приложения путем «обобществления» расходов на инфраструктуру. С точки зрения поставщика, это примерно то же самое, что и снижение стоимости приложения посредством применения тиражного решения (с возможностью настройки и доработки) вместо написания ПО под заказ. Только в одном случае обобществляется разработка, а в другом — эксплуатация. Этот подход подразумевает не только иную организацию хранения данных, но и модель работы приложения в целом, включая аспекты его архитектуры, модель развертывания и организацию обслуживания.

В случае использования медицинской ERP как облачного приложения схема обмена данными в рамках одной организации меняется: обмен производится не между модулями системы /приложениями, а между областями данных. Для обеспечения работы медицинской ERP организации как единого целого используется специальная интеграционная шина — менеджер сервиса. Менеджер знает, какая область данных к какой организации относится, и обеспечивает обмен между ними.

Под запросы клиники

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

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

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

Рост в условиях облачности

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

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

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

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

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

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

Общая схема горизонтального масштабирования облачного приложения приведена на рис. 2.

Рис. 2. Схема горизонтального масштабирования облачного приложения

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

Авторы: Гайдуков Алексей - руководитель разработки 1С:Медицина, gaya@1c.ru;

Игумнова Надежда - методист, igud@1c.ru

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

«По приоритетному направлению – военной технике – нам необходимо резко нарастить объемы производства. Для такого роста требуется радикально сократить производственный цикл, и в этом заключается самая главная сложность», – подчеркивает Артем Вожаков, директор по ИТ «Мотовилихинских заводов».

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

Потребность в прозрачности

До недавних пор на предприятии вообще не существовало никакой автоматизированной системы производственного планирования, процесс был полностью ручным. В ситуации когда выпускаемые изделия – сложные, а производство – многоцеховое, планирование в ручном режиме становится очень труднорешаемой задачей. Объем данных слишком велик, особенно если учесть, что в изделие может входить до 10 тыс. деталей, производимых в несколько этапов. Спланировать гармоничное прохождение изделий через цеха чрезвычайно сложно, этот процесс традиционно «хромал».

В ситуации когда выпускаемые изделия – сложные, а производство – многоцеховое, планирование в ручном режиме становится очень труднорешаемой задачей

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

«Я начал говорить о том, что нам необходимо решение проблемы, еще в 2012 году. Причем речь шла просто о системе управления производством: в качестве платформы рассматривались и западные ERP, и собственная разработка», – вспоминает Вожаков. Руководство и само приходило к пониманию этого. В итоге в 2014 году стартовал пилотный проект «1С:ERP».

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

Однако в 2014 году в компании сменилось руководство и, соответственно, изменились подходы к управлению предприятием. Например, были сильно увеличены требования к росту, что повлекло изменение концепции проекта: речь пошла о внедрении комплексной системы управления производством. В плане проекта появились блоки логистики и складского учета, продаж и закупок, учета фактических затрат. Границы проекта радикально расширились, скорректировались и его масштабы. Если раньше планировалось одновременное внедрение на двух заводах холдинга, то сейчас с учетом возросшей сложности работ ограничились одним заводом. Тиражирование разработанного решения на второй завод и остальные предприятия будет проведено в 2016 году.

Выбор платформы

Конкурс по выбору партнера и платформы для реализации проекта состоялся в 2013 году. Его итоги оказались очень неоднозначными.

«Зарубежные гранды – SAP, Oracle и т. п. – на Западе себя хорошо зарекомендовали, но, если честно, я скептически отношусь к внедрению их продуктов в России, особенно в сложных производствах», – признается Вожаков. Не говоря уже о значительной стоимости решений, очевидны ограничения: компания производит военную технику, и мог наступить день, когда их использование стало бы проблематичным. Кроме того, на многих предприятиях известны большие проблемы, связанные с адаптацией этих решений под специфику производства в России.

На другой чаше весов были отечественные решения, которые обладали сходными недостатками. Исторически они развивались как бухгалтерские системы, и сама их структура говорила, что для решения задач «Мотовилихи» – управления сложным производством – они подходили с очень большой натяжкой. Эти рассуждения справедливы и в отношении существовавшего тогда решения «1С:УПП».

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

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

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

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

Вдвое быстрее

Все новое руководство компании – люди достаточно опытные, они пришли с КамАЗа, где реализуется проект SAP. Они понимали все проблемы, которые могут возникнуть, и были готовы к ним, имея варианты решения.

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

Идеология бережливого производства пришла на предприятия «Мотовилихи» с новой командой управленцев, многие подходы позаимствованы у КамАЗа. Конечно, они требуют адаптации, так как между двумя моделями – крупносерийным конвейерным производством и мелкосерийным производством на заказ – есть сильные отличия.

Идеология бережливого производства пришла на предприятия «Мотовилихи» с новой командой управленцев, многие подходы позаимствованы у КамАЗа

«Производство – это наиболее критичный для нас функционал ERP, – подчеркивает Вожаков. – Мы понимаем, что гораздо проще было пойти другим путем – например, начать с перевода в “1С” бухгалтерского функционала, уже реализованного в другой системе. Такой проект пошел бы гораздо легче». Однако оптимизация производственных процессов чрезвычайно актуальна, и она должна состояться как можно быстрее.

Показатели достижения целей проекта – это двукратное сокращение производственного цикла, изготовление 100% заказов в срок, а также минимизация отклонений фактической себестоимости от плановой. Это принципиальные цели для достижения в рамках проекта. Есть и цели второго уровня – например, двукратное сокращение запасов и объемов незавершенного производства. Практика и анализ процессов, в частности потерь времени при производстве, показывают, что такие цели абсолютно реальны.

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

Реорганизация процессов

«У нас есть ряд механизмов, являющихся нашими ноу-хау. Мы одни из первых, кто их использует – по крайней мере, на практике, – говорит Вожаков. – Главным является управление производством массовых позиций, ставшее штатным механизмом “1С:ERP”. Мы можем определять в составе изделия позиции массовой применяемости и настраивать для них особый вид обеспечения, чтобы производить эти детали не под заказ, а по потребности, на склад. При формировании заказа на изделия такие детали не планируются к производству – для их создания запускается специальная процедура в виде отдельного заказа. Но самое главное – система при этом позволяет поддерживать обратную связь. Если начинаются проблемы с производством массовых позиций, она сигнализирует, что будут проблемы с выполнением основного заказа».

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

Интеграция ERP-системы с методиками и подходами бережливого производства – еще одна важная часть проекта.

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

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

Окупится за полгода

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

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

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