Как избежать зависимости от поставщика программного обеспечения?

Разработка ИТ-системы по индивидуальному заказу имеет множество преимуществ. Заказчик получает продукт, идеально подогнанный под его потребности с учётом специфики деятельности. Однако это приводит к риску попадания в зависимость от поставщика. Что может сделать фирма, чтобы избежать этого?

ОРИГИНАЛЬНЫЙ ТЕКСТ НАХОДИТСЯ ЗДЕСЬ.




В чём заключается «зацикливание на поставщике»?



          Чёткого определения ситуации, когда вы привязаны к поставщику, нет. Однако предполагается, что речь идёт о ситуации, когда клиент настолько зависит от продуктов или услуг в области ИТ (да и в других областях), что прекращение этой зависимости требует больших расходов, чем потенциальная выгода от сотрудничества.

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

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

          Компании, использующие специализированные решения, такие как ERP, CRM или WMS-системы, особенно подвержены риску «зацикливания на поставщике». Чем сложнее такая система, тем выше риск возникновения зависимостей.

          Значит ли это, что использование программного обеспечения, созданного под индивидуальный заказ, является плохой идеей? Однозначно нет! Однако те, кто прорабатывают условия сотрудничества, должны учитывать вероятность «зацикливания на поставщике». На полях документов надо обратить внимание на то, что

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

Комментарий блоггера.  KNF — это Komisja Nadzoru Finansowego, то есть Комиссия финансового надзора Польши. Это польский регулятор финансового рынка. КНФ осуществляет надзор за банками, страховыми компаниями, рынком ценных бумаг, пенсионными фондами и другими участниками финансового рынка в Польше. Конец комментария.


Как избежать зависимости от поставщика?


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



  • Договорные соглашения. Ключевую роль играет чётко очертить желания и возможности заказчика. Необходимо подробно оговорить, какие решения предоставит поставщик и каковы условия расторжения договора. Необходимо обозначить допустимые пределы модификации программы, которые подпадут под законы об авторском праве и смежных правах.
  • Условия передачи заказчику авторских прав. Пользование продуктом, созданным другим лицом, возможно, если пользователь будет иметь соответствующую лицензию. На практике такое делается договором о передаче авторских прав (можно сравнить с договором купли-продажи) или выделением лицензии (можно сравнить с арендой), а также тщательно оговоренной сферой применения. Важно, чтобы условия эксплуатации были подогнаны под потребности заказчика. Может казаться, что лучшим решением будет передача прав, но это бывает далеко не всегда. Когда система создана с нуля, то это действительно выгоднее экономически. Однако, например, для облачных сервисов обычно достаточно только лицензии, которая к тому же и обходится дешевле.
  • Передача знаний и документации. В договоре надо учесть интересы сторон в случае прекращения сотрудничества. Крайне важно обязать подрядчика после расторжения контракта предоставить документацию, исходный код и другую необходимую информацию. Сегодня это актуально там, где используются нишевые или редко используемые решения.

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


Можно ли «спрыгнуть» с этой зависимости?




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

      Многое зависит от содержания договора. Часто условия сотрудничества возможно пересмотреть. Нужно также определить, что именно теряет компания, продолжая пользоваться этим сервисом, и во сколько обойдется смена поставщика? На практике предприниматели отдают предпочтение решению, где меньше риск «зацикливания на поставщике». Рекомендуется также для каждого бизнес-процесса подбирать своего разработчика.

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

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


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

          Периодически занимался и другим экономическим софтом, – «Финансы без проблем», «Толстый Ганс», «Финэксперт», «АБ-офис», «Дело Про». Поэтому по теме польской статьи могу высказаться.


          Весь экономический софт делится на четыре категории:


1.    Бухгалтерское программное обеспечение.

2.    Оперативный учёт и отраслевые решения на стандартной платформе.

3. Комплексная конфигурация – к программе второго типа добавлены механизмы формирования бухгалтерских проводок и соответствующие отчёты перед госструктурами.

4.    Софт, написанный с нуля.


          Программы первого типа, ИМХО, являются просто калькулятором для составления отчётов в налоговую. Конечно, в неё можно внести изменения в соответствии с потребностями пользователя, но это неизбежно приведёт к тому, что обновить программу в соответствии с законодательством сможет только специалист поставщика – «зацикливание на поставщике» во всей красе. Когда раньше, когда позже, но другого финала такого «квазиоперативного учёта" я не видел.

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

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

          Но вот у нас настолько нестандартная специфика, что нужно нанимать разработчика. Первый совет – не пытайтесь поручать ему организацию бухгалтерского учёта! Пусть пишет, что вашей душе угодно, но стандартный бизнес-процесс «Счёт – Оплата – Налоговая накладная – Отгрузка/Акт» - это прерогатива стандартной бухгалтерской программы. Если конфигурация специально под вас радикально изменена или написана с нуля на той же платформе, что и стандартная бухгалтерия, то организуйте конвертацию данных из одной базы в другую с помощью соответствующего конструктора. Если используется другой софт, то задача переноса данных усложняется, но не настолько, чтобы стать непреодолимой проблемой. Моей команде приходилось их успешно решать.



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


ЧТОБЫ БЫТЬ В КУРСЕ ПОСЛЕДНИХ НОВОСТЕЙ, ПОДПИСЫВАЙТЕСЬ НА Telegram-канал «КАРЬЕРА МЕНЕДЖЕРА И Информационные Технологии».


ВЕРНУТЬСЯ К ГЛАВНОМУ МЕНЮ

```