Интеграция — быть или не быть? Семь вопросов самому себе
Проекты по настройке интеграции, как правило, сложнее, чем кажется на первый взгляд. К ним нужно подходить со всей осознанностью, чтобы не попасть впросак. На внедрениях системы мы в компании Directum, которая разрабатывает решения для цифровизации бизнеса, постоянно видим этому подтверждение. Какие вопросы стоит задать себе перед стартом проекта — расскажем в этой статье.
Представим, что компания собирается внедрять информационную систему (ИС) для организации электронного документооборота. Вас поставили ответственным за проект, дали вводные и сказали, что нужно интегрировать ИС с текущей программой. Какой именно — CRM, ERP — не столь важно. Задача поставлена — нужно исполнять.
В нашей практике работы с заказчиками Directum были случаи, когда контактное лицо занимало позицию: «Нам надо — и всё». Звучит, как будто клиент знает, что говорит, но на деле оказывалось, что вопрос логически не был обоснован.
Предлагаю трезво взглянуть на ситуацию, задать себе и руководству правильные вопросы и в итоге решить: точно ли нам требуется интеграция с другими системами?
Вопрос № 1. Кто бизнес-заказчик интеграции?
Определите сотрудников, которым интеграция будет необходима, полезна, и, самое главное, выясните, для чего именно она им нужна. Уточните: как часто будут пользоваться функциональностью, сколько времени сотрудники будут тратить, если заносить информацию в две системы. Если это лишние 40 секунд раз в 2 недели — повод задуматься. Но иногда слово владельца бизнес-процесса и спокойствие в работе важнее любой цены — в этом случае делаем синхронизацию двух систем!
Пример из практики. Клиенту требовалась интеграция справочника «Контрагенты» из системы «1С: Бухгалтерия». Заказчиком была главный бухгалтер. Новый контрагент в организации появлялся примерно раз в неделю-полторы. В условиях ограниченного бюджета стоило бы оставить интеграцию на 2-й этап проекта, а пока вносить контрагентов в обе ИС вручную. Но! Решающим фактором стало именно спокойствие бизнес-заказчика. Гендиректор сказала, что, если главный бухгалтер довольна и у нее хорошее настроение, это важнее, чем сумма за работы по интеграции двух систем.
Это отличный пример соотношения ценности-цены и весомого слова главного бухгалтера, от настроения которого зависит зарплата трехсот человек.
Второй пример. Крупная компания, локальная поставка ИС, масштабный проект внедрения, на котором необходимость совмещения с CRM-системой отстоял целый отдел. Проведя анализ процесса, мы предлагали не стартовать интеграцию, привели доводы и примеры прошлых проектов. Несмотря на это, проект всё же был реализован по желанию заказчика. На модификации потратили более 400 тыс. руб. В работе функциональностью не пользовались ни разу за полгода.
Вопрос № 2. Готовы мы описать процесс интеграции в тех. задании/чек-листе?
Удивительно: заказчики иногда приходят с запросом интеграции, но при этом у них нет понимания, зачем она им.
Мы задаем стандартные вопросы, чтобы определить цель клиента и первостепенную задачу. К сожалению, чаще всего не получаем ответов, потому что контактное лицо не понимает всей цепочки и целей бизнеса. Мы всегда предоставляем чек-листы по интеграции, но в 90% случаев их не заполняют, просто потому что не знают изначальную боль.
Для грамотной оценки интеграции потребуется «выплеснуть на бумагу» те задачи и тот процесс, который пока что находится в вашей голове или голове бизнес-заказчика.
Пример из практики. Компания 180 человек. Контактное лицо, с которым велись все переговоры, — помощник ГД. Задача: интеграция счетов, проводки оплат с банк-клиентом. Заказчик — бухгалтерия. Чек-лист мы предоставили при первом же общении, озвучили важность заполнения. Стоило бы направить его бизнес-заказчику для корректного описания процесса и уточнения задач интеграции, но клиент по своим причинам решил этого не делать. Чек-лист самостоятельно заполняла помощник ГД. Мы проводили оценку «из того, что есть». В итоге, когда к обсуждению спецификации подключилась бухгалтер, оказалось, что данные не отражали и 30% реальных задач бухгалтерии. Пришлось пересчитывать по новым вводным, а это, конечно, потребовало времени.
Из примера ясно, что стоимость проекта интеграции — дело тонкое, индивидуальное. Не бывает двух одинаковых компаний с абсолютно идентичными версиями систем и задачами. Вы — уникальны, а значит и оценка интеграции тоже. Без конкретики вендор сможет предоставить лишь верхнеуровневые оценки стоимости или вилки цен. Чтобы было «точно, как в аптеке», нужно всё структурировать и прописать. Важно понимать, как будет работать процесс интеграции от самого первого нажатия кнопки сотрудником до итогового результата.
Если вас назначили руководителем проекта (РП), не нужно тянуть всё на себе, делегируйте, просите помощи у тех коллег, которые являются владельцами бизнес-процесса, задавайте им уточняющие вопросы.
В случае, когда ответы никто предоставить не готов, можно сделать вывод, что интеграция не столь важна. Не делаем или оставляем на следующий этап развития системы.
Вопрос № 3. Сколько документов/контрагентов синхронизируется из одной ИС в другую?
Пример из практики. IT-компания. В штате — 200 сотрудников, которые подкованы в терминах и понимают всю внутреннюю кухню. Из общения на встрече стало ясно, что количество актов, которые нужно перенести из 1С в Directum RX, — всего 120 штук в год. Занесение одного акта в систему занимает примерно 1-2 минуты, то есть речь шла о 20 минутах в месяц.
На первый взгляд, совсем не критичное количество документов и времени их обработки, а значит, можно и не настраивать связь между системами. Но из общения с бизнес-заказчиком стало понятно, что просрочка подписания и тем более потеря каждого акта в компании выливается в штрафы от 50 до 200 тыс. рублей, а это — уже реальная боль заказчика. Поэтому даже мыслей не возникло не стартовать проект по интеграции.
Количество документов — очень значимый фактор для принятия решения. Если речь идет о цифре до 50 документов в месяц и время на их занесение не столь критичное, разумнее оставить ручное занесение. В случае, когда количество документов растет, двойная работа занимает больше 20% времени от рабочего дня, настраиваем интеграцию.
Вопрос № 4. Открыта ли наша ИС для интеграции?
Текущая система может располагаться у вас на сервере или в облаке поставщика, может быть закрытой или открытой для интеграции со смежными ИС.
К системам с открытым доступом вопросов нет. Загвоздка в закрытых системах. Недоступны они могут быть по разным причинам: не пропускает отдел информационной безопасности компании, вендор не дает доступа к своему центру обработки данных (по нормам всё той же инфобезопастности) и другим.
Уточните у вашего IT-специалиста уровень доступа к ИС. Если она — неприступная крепость, отказываемся от настройки интеграции.
Пример из практики. Компания 150 сотрудников, локальная поставка на сервер заказчика, интеграция с «1С: ERP Управление предприятием» по справочнику «Контрагенты» и телам финансовых документов. Прислали полный и корректный чек-лист по системе для интеграции, но строка «возможно ли дать доступ к текущей ИС тех. специалистам вендора» испортила всё настроение. В поле стоял ответ: «Нет, служба безопасности не разрешает доступ». Звонок контактному лицу, вопрос: «Виталий, а как же, собственно, мы к вам подключимся, если не будет допуска?». Десять секунд молчания в трубке, и контактному лицу стало понятно, что всё же придется добиваться разрешения для настройки интеграции.
Вопрос № 5. Наша система сложна в доработке? Кто будет заниматься проектом?
Уточните у IT-отдела, насколько сложно доработать вашу текущую ИС. К сожалению, пока не придумали волшебной кнопки, которая бы за 5 секунд интегрировала две системы между собой. Настройка интеграции — как строительство моста между двумя берегами. Мало поставить сам мост, нужно закрепить его. Проводятся точечные настройки и иногда доработки на сторонах обеих систем.
Учитывайте, что ваша ИС может быть существенно модифицирована, что повлечет за собой сложности для тех. специалистов. Этот фактор обязательно озвучьте вашему менеджеру.
В этом же пункте отмечу еще один подвопрос: «У нас в штате есть IT-специалист со знанием разработки?». Не системный администратор, а именно разработчик. Как я писала выше, доработки потребуются и на стороне вашей системы. Обычно заказчик их выполняет своими силами, а в случае, если сделать это самостоятельно не получается, потребуется право доступа для специалистов исполнителя.
Если доступ возможен, разработчик в компании имеется — ставим жирный плюс к возможности настройки интеграции. Делаем!
Пример из практики. Компания небольшая — 30 сотрудников, но вопрос интеграции с 1С был критичным из-за большого объема документов, около 3000 в месяц. Изначально вопросы доработки текущей системы возложили на разработчика, который курировал 1С заказчика. По словам РП, он должен был знать, как происходит вся настройка, да и опыт работы более 5 лет не оставлял сомнений. Следовательно, часы тех. специалистов вендора для донастройки системы на стороне заказчика не были заложили в расчеты и бюджет.
В результате всё пошло не по плану. Разработчик заказчика сказал, что не сможет сделать донастройку, в срочном порядке исследовали систему клиента, пересчитали спецификацию, добавили часы нашей работы, чтобы выполнить модификации на стороне заказчика. Это потребовало дополнительных усилий с обеих сторон и увеличило сроки проекта на 2 недели.
Вопрос № 6. Есть бюджет и силы на последующие обновления интеграции?
Не секрет, что вендор выпускает новые версии продукта. В каждой последующей конфигурации могут быть критичные доработки, влияющие на текущее состояние измененной у вас системы. И если настроенная интеграция отлично справляется с задачами на первой версии, то есть риски, что на второй «мостик» работать не будет.
Задаем себе вопросы: у нас есть ресурсы IT-специалиста для донастройки? Есть бюджет на эти доработки? Есть желание поддерживать интеграцию в будущем? Есть время на процесс?
Пример из практики. Крупная компания более 500 сотрудников размещается в облаке вендора. Настроены интеграции с несколькими системами: CRM и ERP. При выходе новой версии у любой из трех систем — Directum RX, CRM и ERP — IT-отдел компании сначала проверяет, какие именно внесены изменения, как они себя проявят, если накатить обновления, сломает ли это настроенную интеграцию. Клиент проводит обновления не каждый квартал с выходом новых версий, а один раз в год, т. к. процесс занимает не один день. Ежеквартально проводить его затратно как по часам, так и по бюджету.
Вопрос № 7. Мы проводим интеграции в облачной поставке системы или локальной?
Ранее я уже упоминала, что вы можете купить систему как в облаке поставщика — облачная поставка, так и получить дистрибутивы ПО, разместив их на своем сервере, — локальная поставка. Функциональность системы от этого не изменится, но подход к реализации интеграции будет разным.
У некоторых вендоров систем облачная поставка не предполагает модификации и интеграции с другими ИС. Вы приобретаете программный продукт, как он есть и задуман вендором. Этим объясняется приемлемая цена на подписку, т. к. используется нечто тиражное и типовое.
Всё содержание облака, обновление системы — на плечах исполнителя, и вы даже не задумываетесь над этими вопросами. Но при этом нет возможности синхронизации с другими ИС и доработки под свои локальные задачи. Если вы планируете интеграции и при этом вам требуется именно облачная поставка, то в некоторых случаях вендор разворачивает для вас частное облако (выделяет отдельный независимый сервер), либо стоит сразу рассматривать локальную поставку.
Пример из практики. Компания до 25 сотрудников, своего сервера нет, IT-специалиста и разработчика тоже нет, выделять бюджет на свой сервер и нанимать IT-сотрудника не планировали. Гендиректор строго обозначил задачу: «нужна интеграция с 1С», готовы были заполнить чек-лист. Отсутствие сервера однозначно склоняло к облачной поставке системы, но при этом стоимость частного облака не проходила по бюджету.
Проверяли задачу на истинность. ГД принял решение поработать полгода в типовой конфигурации системы в облаке и написать тех. задание на будущую интеграцию с полным осознанием текущих реалий. Прошло уже полтора года, как заказчик работает в облаке, отдел сопровождения ещё уточняется по задаче интеграции, но, как оказалось, она была не такой актуальной.
В заключение хочу призвать любого руководителя проекта к логическому подходу к интеграции. Всегда можно заложить бюджет, написать тех. задание, придумать много разных задач для интеграции и даже реализовать её любой ценой, но всегда проводите проверку на логику.
Задавайте себе вопросы: зачем нам это? Кто и как часто будет использовать? Что произойдет, если не настраивать интеграцию? Как много времени мы сейчас тратим на исполнение этого процесса? Какие риски, если не делать синхронизацию? Несем ли мы убытки (любые), если интеграции нет?
Делитесь в комментариях примерами синхронизации систем в вашей компании. Как вы принимали решение, и какие задачи ваша интеграция решает? Кому и как она помогает?
Комментарии 0