Стоит ли стартапу работать с Enterprise?
Игорь Рябенький на 14-ой VC Кухне от Startup Kotiki, которую проводит Игорь Шойфот, поделился советами из личного опыта по работе стартапов с корпорациями. Мой вольный пересказ:
1. Если можешь не работать с Enterprise – не работай. Это долго.
2. Если всё-таки приходится работать с Enterprise, то это может быть в двух вариантах:
Вариант 1: Корпорация – как ваш канал продаж.
Лучше всего постараться сделать свои каналы продаж, потому что:
а) Долго и муторно договариваться с корпорацией.
б) Мало договориться с корпорацией о продажах вашего продукта, нужно ещё суметь «продать» его её сейлзам, чтобы те захотели его продавать своим клиентам.
Вариант 2: Корпорация – как ваш заказчик, клиент, покупатель вашего продукта.
Делайте продукт так, чтобы у него было больше распределённого спроса.
Если у вас будет много такого распределённого спроса, то есть много разных клиентов, то:
а) Большие корпорации начнут приходить сами.
б) Вам будет намного легче заходить к ним. Это уже не будут классические Enterprise-продажи годами – сделки будут заключаться за неделю-другую.
Amazon потенциально самый опасный конкурент и для мелкого предпринимателя и для крупного производителя успешного товара. Начиная играть на его доске, нужно помнить, что правила могут поменяться в любую минуту и всегда это будут изменения в пользу Amazon. Подписывая соглашение о сотрудничестве, вы чуть ли не подписываете договор с дьяволом и…
Автоматизировать нельзя оставить. Зачем вашей команде Enterprise-приложение
Как собрать в прямом эфире 17 000 зрителей? Значит, рецепт такой. Берем 15 актуальных IT-направлений, зовем зарубежных спикеров, дарим подарки за активность в чате, и вуа-ля — крупнейший в Украине и восточной Европе онлайн-ивент готов. Именно так прошла ежегодная мультитул конференция NIXMultiConf.
Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.
По мотивам докладов экспертов NIX продолжаем серию статей на самые актуальные темы. На этот раз Business Analyst Наталия Федосеева рассказывает о пользе Enterprise-разработок в командах и делится личным опытом внедрения таких проектов.
Привет! Я — Наталия Федосеева, Business Analyst в NIX c 2015 года. Уже три года занимаюсь Enterprise-проектами в нашей команде. Мы выросли от Excel-таблиц до крупных Enterprise-систем. Оба решения хороши на разных этапах развития команды. Что лучше — решать вам. Я же хочу рассказать, когда Enterprise-приложение может облегчить жизнь, и на что обратить внимание при выборе готовой системы.
Enterprise-проект — это программное обеспечение, которое организация использует для достижения внутренних целей и решения корпоративных задач. Автоматизация бизнес-процессов помогает повысить эффективность работы и обеспечивает функциональную поддержку бизнес-логики.
Рынок Enterprise-решений сформировался из основных нужд компаний:
Несмотря на обширный выбор, огромная доля рынка остается в категории «Другое». Готовые решения по разным причинам одним компаниям не подходят вовсе, а для других — удовлетворяют потребности лишь частично. Все смотрят в сторону трендов Enterprise. Если ваша команда тоже хочет внедрить такой проект, выясните несколько моментов.
Как выбрать «свое» и не переплатить
Перед внедрением любого новшества я рекомендую обратить внимание на:
Более безопасными позиционируются облачные решения. У них уже профессионально организована работа с серверами как со стороны Hardware, так и со стороны Software. Тем не менее, если компания может позволить себе On-premise решения и готова самостоятельно следить за безопасностью, она может быть более спокойна за сохранность своих данных.
В NIX — гибридная система внутренних решений. Относительно несложные бизнес-процессы мы автоматизируем с помощью готовых on-premise систем. Как мы к этому пришли?
Инициатива — валидация — разработка — Enterprise!
Когда-то у нас была маленькая команда и для ведения дел достаточно было таблиц и рассылки на почту. Сегодня все в корне изменилось. От офисных документов мы перешли на полноценные продукты и разработали собственные. Для несложных задач пользовались документами, которые все же требовали время на их поддержание в актуальном состоянии. Какие-то процессы инициативные группы разработчиков потихоньку автоматизировали сами, в свободное от коммерческих задач время. Так появились системы бронирования комнат, девайсов для тестирования, заказа еды.
К хорошему все быстро привыкают. Проекты зажили своей жизнью и стали нуждаться в еще большей поддержке. Когда потребовалась максимальная вовлеченность, мы выделили ответственные команды под каждый проект. Спустя время увидели, что у них возникают похожие проблемы. Поэтому создали комитет, в котором обсуждали архитектурные решения и вырабатывали единый подход, чтобы синхронизировать ведение этих проектов. Для базовых кастомных приложений сформировалась отдельная команда со своим Product Owner. Специалист контролирует все потребности NIX. Например, так произошло с бизнес-процессом букинга комнат для переговоров. Изначально бронирование было «на коленке», потом инициативная команда разработчиков создала функциональное приложение. На момент релиза это было отличное улучшение. Но основной процесс бронирования комнаты был не совсем удобным, и бронь занимала довольно много времени. Позже разработали новое приложение с другими технологиями, которое уже стало частью Enterprise-системы.
Многие налаженные процессы продолжают успешно функционировать и приносить свои плоды, а некоторые еще в процессе становления. Старые решения постепенно отмирают и трансформируются в связи с новыми запросами и возможностями автоматизации. Таким же образом, по мере изменения процессов, выстраиваются и способы их автоматизации.
Каждую инициативу Product Owner оценивает на жизнеспособность. Затем идею обсуждает рабочая группа, выбирается ответственный за принятие окончательного решения. Если команда поддерживает инициативу, идея переходит на стадию предпроектного анализа. Аналитики получают оценки, вырабатывают требования, рассчитывают экономическую эффективность. Последнее — крайне важный момент.
Например, у нас есть шкафчик для хранения девайсов и система, через которую их бронируют. Каждый отмечает, что он взял, вернул или передал девайс другому. Бывает, кто-то не успел записаться или пока дошел до базы, нужную вещь уже перехватили либо устройство оказалось разряжено. От команды поступила инициатива поставить автоматическую систему, которая считывала бы состояние шкафчика — количество девайсов до открытия двери и после. Мы просчитывали экономическую выгоду от автоматизации общей системы слежения за девайсами для тестирования. В итоге поняли, что посадить условную бабушку с журналом было бы гораздо дешевле. Поэтому пока остановились таком варианте: ребята вручную отмечают в системе, что взяли девайс.
Задача бизнес-аналитика — из «пазлов» собрать цельное решение
Большой плюс в создании разработки для своей команды — доступ к стейкхолдерам. Однако их много, и учесть мнение каждого — та еще задача. Способы сбора требований зависят от количества стейкхолдеров. В процессе переработки старой системы мы собирали фокус-группы, с которыми обсуждали подготовленное нами видение новой системы на базе прототипов. Такой подход оказался эффективным. Мы обсуждали конкретный пример, а не просто тратили время на брейншторм. Для себя мы вынесли полезную практику — ходить на такие презентации вдвоем. Пока один аналитик работает с группой, второй — на ходу делает ценные наблюдения «в полях» и тут же фиксирует их.
Когда важно было понять определенные количественные показатели, мы пользовались опросниками. Чтобы выявить тонкости в некоторых бизнес-процессах, наблюдали за деятельностью конечных пользователей. Это очень интересно. Иногда можно заметить инсайты, о которых пользователи не догадались бы рассказать вслух.
В нашем случае самым популярным способом сбора требований оказалось личное интервью. Формат показывает себя наиболее эффективно. Стейкхолдер может высказать требования не только по конкретному вопросу. Любая информация от него может пригодиться в других разработках. И что особенно важно — во время интервью выстраиваются доверительные отношения к команде, а вместе с ними повышается лояльность к продукту.
Важно тщательно опросить стейкхолдеров, чтобы учесть потребности всех ребят. У нас был случай, когда мы меняли форму в старой системе. Нам назвали людей, которые ею пользуются, мы их опросили и выяснили, что одна из фич уже не актуальна. В процессе работы над совершенно другим функционалом выяснилось, что именно эта функция очень нужна другому человеку, о целях которого мы не знали. Но все обошлось — мы вернулись фичу на доработку.
Конечно, можно и микроскопом гвозди забивать. Но лучше делать целесообразные вещи. Фича N сократит затраты времени определенных сотрудников на N часов в неделю — звучит круто. Если мы понимаем, что решение улучшит качество работы и разработка фичи экономически целесообразна, отправляем идею на утверждение. Финальный этап — непосредственно создание продукта. После этого тестируем пробную версию, собираем отзывы стейкхолдеров и постепенно запускаем проект.
В крупной компании для сбора фидбеков подойдет матрица Importance/Influence. Для каждой из подсистем выделяем роли, ключевых представителей и уровень влияния на них определенной системы. Так видим, кого нужно опросить, у кого получить одобрение, кого просто уведомить об изменениях. Все данные наносим на карту.
Оповещения об изменениях высылаем на почту целевой аудитории и передаем новость через лидов. Параллельно обновляем ссылки во всех инструкциях и готовим гайды для пользователей. Документ нужно писать простым языком, чтобы на поиск ответа ушло минимум времени. У нас лучше всего прижились гайды в формате FAQ для несложных процессов и видеозаписи с пошаговой инструкцией для более масштабных.
По своей природе люди как можно дольше хотят сохранять состояние равновесия, поэтому появление новых процессов в команде может вызвать сопротивление или недопонимание. На помощь приходят специалисты User Care. Они отвечают на все вопросы, помогают внести изменения в систему и уладить трудности. Аналитики следят, чтобы User Care знали обо всех обновлениях, что и как работает и в каждом конкретном случае помогут разобраться.
Так что же лучше: приложение или старая-добрая Excel-таблица? Правильного ответа нет. На разных этапах роста у компаний свои потребности. Одни из них закроют готовые Enterprise-решения, для других — понадобятся специальные разработки. А, может, вовсе не нужно изобретать велосипед, и с задачей справится вездесущий Google Docs. Критично относитесь к идеям, учитывайте финансовые возможности организации и, конечно, автоматизируйте все, что можно автоматизировать.
Создавая enterprise — решение завтрашнего дня
Выражаем благодарность за подготовку статьи Павлу Ковтуну — CEO Mycroft Assistant. Павел больше 12 лет
специализируется в области автоматизации бизнеса и supply chain management.Является автором уникальных методик анализа и принятия решений в SCM, создатель первой инновационной системы управления запасами экспертного уровня.
Задача любого бизнеса – эффективное использование имеющихся ресурсов. Для бизнеса, работающего с товарами, одной из основных проблем является эффективное вложение денег в оборотный товар — запасов товара всегда должно быть ровно столько, сколько нужно. Если его больше, чем нужно (overstock), то деньги вложены неэффективно, если меньше (out-of-stock) — то есть вероятность пропущенных продаж, низкого качества обслуживания и потерянных клиентов. Результат — неверное решение проблемы ведет к потерянным деньгам.
Решением этой проблемы занимается отрасль менеджмента, которая называется управлением цепочками поставок – Supply Chain Management. Механизмы, которые используются при решении задач, связаны с обработкой больших массивов данных, математическим моделированием, использованием статистических методов, решением задач оптимизации и машинным обучением.
Большинство компаний решают проблемы поставок просто использованием расчетов Excel, вручную собирая данные, тривиальные формулы и заложенную ошибку, которая незначительна на небольших оборотах фирмы. И до определенного размера и оборота компании этот вариант подходит — есть возможность масштабировать расчеты, нанимая новых менеджеров. Но при росте компании, накопленная ошибка и увеличивающийся объем данных не позволяет вести все расчеты «в ручном режиме» — эффективность работы падает настолько, что в результате постоянной массы неверных решений, неэффективность использования оборотных средств может достигать 30%.
Что же делать бизнесу
Для решения этих проблем есть специальный класс систем, называемый Expert Supply Chain Management (expert-SCM). Такого рода решения самостоятельно следят за данными о текущих продажах и доступных остатках каждого из товара во всех торговых точках (складах). Причем делают это не только у вас, но и у других участников цепи снабжения. И, имея эти данные, с учетом индивидуальных особенностей продаж товаров, в режиме online производят обработку всего гигантского массива данных, вынося решения о том, в какой товар необходимо вкладывать деньги и на какой торговой точке это товар необходимо поставить сейчас, чтобы не было проблем в будущем.
Наше решение – Mycroft Assistant (mycroftbs.ru) является одним из передовых облачных представителей Expert-SCM решений для СМБ. Мы уже больше 5 лет занимаемся SCM-решениями, и наши клиенты подтверждают экономическую эффективность использования наших решений в бизнесе.
Два года назад мы решили собрать наши наработки и накопленный опыт в этой сфере, создав продукт, который наиболее оптимальным образом решает проблемы клиентов. При этом мы поставили перед SCM Mycroft Assistant две задачи:
Каким образом мы спроектировали MycroftAssistant?
Мы изначально решили, что это будет облачное решение, реализованное на зарекомендовавшем себя и знакомым клиентам стеке технологий Microsoft (Azure, ASP.NET, MS SQL), которое сможет работать максимально гибко:
Хоть мы и начали разработку на своем сервере в collocation в датацентре, изначально планировалось для production использовать облако Azure как по бизнес-причинам, так и по техническим соображениям:
Реализация облачной архитектуры была заложена при проектировании Mycroft Assistant как SaaS web-based решения.
Какой стек использовали для реализации?
jQuery, jQuery UI, knockoutjs, flot, Globalize, DataTables, Bootstrap, fancytree
Нашу архитектуру мы выбирали долго и мучительно на старте реализации, но в итоге пришли к наиболее оптимальной, которую можно представить в виде следующей схемы:
SCM Mycroft Assistant состоит, условно, из трех частей: Core, WebAccess, Workers.
Core — набор основных библиотек для общего функционирования системы: общие классы, базовые интерфейсы, компоненты ядра и т.д.
WebAccess — web-доступ на основе ASP.NET MVC. Просмотр и управление данными, настройка, администрирование. Состоит из нескольких подсистем, при этом имеется возможность установить любую другую подсистему, не пересобирая модуль WebAccess. Регистрация подсистем происходит автоматически при старте приложения.
Workers — Azure Worker Role, внутри которых выполняются все расчеты.
В системе реализован механизм «плагинов». Например, для загрузки данных в систему может быть написан плагин, который сможет получить данные из внешней системы по API, которые затем конвертируются во внутренние объекты бизнес-логики и сохраняются в БД. Через плагины также могут быть расширены: уведомления, отчеты, модули расчета данных.
Неплохо, а что насчет нагрузки?
После развертывания в Azure мы получили возможность провести всестороннее комплексное нагрузочное тестирование средствами Visual Studio OnlineОно выявило bottle-neck, который не проявлялся при работе с текущими клиентами.Выглядело это примерно так:
К примеру, если клиент оперирует 50 000 различными товарами на 60 торговых точках, итого, только за 1 день, если рассчитывать все перемещения между различными точками, объем оперируемых записей составляет 50 000 * 60 * 60 = 180 000 000, а для обсчета истории за год (что и должно происходить в рабочем режиме), количество записей больше чем 6.5 * 10^10. С таким объемом Big Data кэш не справляется.
Проблема была в архитектуре кеширования данных — весь кэш был in-memory. Это позволяло сильно сократить ожидания ответов на клиентской стороне, но, при этом, увеличивало расходы оперативной памяти. Если кешировать только информацию, к которой происходит наиболее частое обращение, то это не настолько проблематично, как кешировать все сырые данные.
Решение выявленных проблем
К счастью, мы изначально и планировали переходить на распределенный кэш, но для этого нам надо было перевести фильтрацию и агрегирование данных из LINQ в SQL.
Даже не в LINQ to SQL, а в ручное конструирование запросов, поскольку у нас используется разносторонний срез по различным данным (товары, склады, менеджеры и т.п., да еще и по годам, месяцам и самое “интересное” — по неделям), а Entity Framework функции из кода C# вызывать не умеет, к сожалению (Expression нам не подходил).
Агрегированные данные, во-первых, занимают меньше места в памяти, а во-вторых, мы вообще отказались от кеширования, переложив нагрузку на БД. Ценой несущественного снижения скорости загрузки информации мы победили утечки памяти.
Что получилось в результате?
По результату развертывания решения в Azure и получения возможности использования всех современных «плюшек» которые дает эта платформа, мы пришли к выводу, что наш расчет на получение технических преимуществ от использования технологического стека Microsoft и облачных технологий Azure полностью оправдал себя.
Об авторе
Павел Ковтун — CEO Mycroft Assistant
Больше 12 лет в области автоматизации бизнеса, больше 8 лет предпринимательского опыта. В области supply chain management — 5 лет.
Автор нескольких уникальных методик анализа и принятия решений в SCM, с публикациями в электронных и печатных изданиях.
Создатель первой инновационной системы управления запасов экспертного уровня, предназначенной для СМБ.
Enterprise или SaaS: что выбрать бизнесу
Сперва определимся с терминами:
Software as a Servise: облачная модель размещения ПО. Компания оформляет подписку и подключается через интернет к серверам поставщиков софта. То есть работа осуществляется в облаке и обслуживается провайдером.
В статье будем использовать термины: SaaS и облако.
Enterprise: корпоративное решение, которое разворачивается на собственных серверах компании, покупающей софт у производителя. Работа осуществляется без участия поставщика ПО. Проще говоря, это облако, помещенное в инфраструктуру компании-клиента.
В статье будем использовать термины: Enterprise, In-House, On-premise.
Примеры ПО, у которых есть облачное и Enterprise-решения:
Для того, чтобы понять, какое решение более выгодно для вашего бизнеса, необходимо сравнить SaaS и In-House. Можно провести аналогию с арендой квартиры и покупкой собственного жилья:
Оба варианта предполагают проживание в квартире. Разница в том, что в первом случае это ваша личная квартира, где вы можете самостоятельно сделать ремонт, поставить мебель и вообще делать все, что душе угодно. Во втором случае вы живете на съемной квартире, где действуют свои правила и ограничения согласно договору.
То же работает в отношении облака и On-Premise: вы пользуетесь «арендованным» софтом, находящемся в ответственности провайдера, или приобретаете сервис, где «хозяин» вы сами.
Как это работает с чат-центром
SaaS: сообщения клиентов сперва попадают на серверы WhatsApp, Telegram, Viber и прочих мессенджеров. После этого они попадают на серверы чат-центра. Далее вы подключаетесь через интернет к серверам чат-центра и видите сообщения ваших клиентов. При этом на пути следования данных есть посредники — интернет провайдеры и DNS-сервера.
Enterprise: сообщения клиентов поступают на серверы мессенджеров, откуда попадают напрямую к вам. В этой цепочке отсутствуют посредники, провайдеры и поставщики.
Нужен ли вам In-House?
Существует мнение, что In-House выбирают только крупные государственные и финансовые организации. На самом деле, такой тип подключения пользуется не меньшей популярностью среди сотовых операторов, транспортных и логистических организаций, страховых компаний. Это частные компании с большим числом клиентов и высокой нагрузкой на операторов.
Каждая компания, которая работает с персональными данными клиентов, несет ответственность за личную информацию и попадает под действие закона №152-ФЗ «О персональных данных». Enterprise-решение в таком случае помогает более четко следовать закону, чем SaaS.
Особое значение в пользу корпоративного решения имеют скорость и стабильность. Чем больше сообщений принимает чат-центр, тем больше нагрузка на серверы компании. Отсюда низкая скорость переписки. Для того, чтобы операторы могли общаться с клиентами без задержек, необходимо поддерживать высокую производительность системы. Такую возможность предлагает On-Premise.
Преимущества Enterprise
1. Безопасность информации
Для любой компании важно, чтобы личные данные клиентов и конфиденциальная информация не ушли на сторону. Поэтому большое значение придается цифровой безопасности.
1.1 Персональные данные
Клиент, общаясь с компанией, зачастую передает свою личную информацию: реквизиты банковских карт, паспортные данные, номер телефона — конфиденциальную информацию, которая не должна попасть в руки третьих лиц. In-House решение позволит хранить всю информацию на своих серверах, что исключает утечку личных данных.
1.2 Данные компании
Бухгалтерия, базы данных, документация и сведения о компании тоже являются конфиденциальными данными, требующие повышенной защиты от лишних глаз. On-premise подразумевает, что все это хранится на серверах компании, доступ к которым есть только у сотрудников организации.
Закон 152-ФЗ «О персональных данных» гласит:
«Операторы и иные лица, получившие доступ к персональным данным, обязаны не раскрывать третьим лицам и не распространять персональные данные без согласия субъекта персональных данных, если иное не предусмотрено федеральным законом»
Несоблюдение закона влечет за собой гражданскую, административную и уголовную ответственность. Это значит, что компания, допустившая утечку конфиденциальной информации, оплатит штраф или лишится лицензии на свою деятельность.
Chat2Desk оснащен системой безопасности, которая предоставляет доступ только тем, кто авторизовался в системе. Вся информация зашифрована, а значит, даже если произойдет взлом или утечка, то расшифровать данные смогут только какие-нибудь спецслужбы. В отличие от SaaS, In-House исключает посредника между клиентом и компанией, поэтому безопасность такого решения выше. Поэтому компании со статусом оператора персональных данных будет проще следовать закону. Но тогда владелец Enterprise берет ответственность на себя и самостоятельно внедряет систему мониторинга защиты данных.
2. Стабильность и скорость
Доступ к облаку обеспечивается интернет-провайдерами. Компании обеспечивают постоянную работу сервиса за счет мощностей своих серверов и поставщиков интернета. Но это не исключает возможных сбоев в работе, на которые вы не сможете повлиять.
При подключении In-House вы самостоятельно находите провайдеров и ответственность за работу интернета переходит под ваш личный контроль. Теперь любые возникшие трудности решаете вы сами.
Но если вы используете In-House-решение Chat2Desk для внутренней работы отделов, то никакие сбои и задержки вам не страшны. Внутри одной локальной сети документы и сообщения передаются без проблем.
Например: ваш офис расположен на Кипре, а облако Chat2Desk развернуто на российских и европейских серверах. В таком случае вы можете столкнуться с низкой скоростью доставки сообщений и сбоями в работе сервиса. Размещение On-Premise решает эту проблему: работа сервиса не будет зависеть от сторонних посредников и вы сможете свободно общаться внутри компании.
3. Кастомизация софта
Если речь идет о доработках внутри сервиса, то облако имеет ограничения. Каждый провайдер софта имеет roadmap, где запланированы обновления и доработки. Если ваша идея попадает в область roadmap, то вы поймали удачу за хвост – предложение рано или поздно реализуется. Но если ваше предложение идет вразрез с планами сервиса, то придется доплачивать, чтобы софт сделали под потребности вашего бизнеса.
In-House-решение дает возможность самостоятельно кастомизировать и адаптировать софт под ваши нужды. Открытый API позволяет разработчикам вашей компании вносить изменения, проводить дополнительные интеграции со сторонними облачными сервисами, искусственным интеллектом, системами безопасности и собственными чат-ботами, независимо от создателей софта.
Кроме функциональной части вы можете изменить внешний вид интерфейса, например, разместить в углу экрана логотип компании. Настройте виджет на сайте компании: разработайте свой дизайн, а вместо Chat2Desk укажите название компании.
4. Производительность
При работе с SaaS подключаются две стороны — компания и клиенты. Работа и общение проходят внутри облака, ресурсы и возможности которого достаточно широки, однако имеют свои ограничения. Например, в случае высокой нагрузки возможны сбои и задержки в работе софта. Скорость будет на низком уровне до тех пор, пока владельцы сервиса не повысят мощности.
В случае с In-House ситуация меняется: вы сможете самостоятельно регулировать мощность сервера и увеличивать ее в особых случаях. Представьте себе ситуацию: вы запускаете рекламу с выгодным предложением. Вы сможете спрогнозировать наплыв клиентов и вероятную нагрузку на сервера и вовремя принять необходимые меры.
Требования для Enterprise
Технические требования рассчитываются индивидуально и зависят от ваших целей и ожиданий. Главные критерии — объем сообщений, число операторов и количество подключенных мессенджеров.
Чтобы развернуть On-Premise на своем сервере, необходимо соблюдение следующих условий:
1. Оборудование:
2. Отдел разработки: чтобы развернуть In-House на серверах, необходимы специалисты с обеих сторон. Однако, если у вас нет своих разработчиков — это не проблема. Chat2Desk готов полностью настроить Enterprise самостоятельно.
3. ПО: не имеет значения, так как универсальные решения Chat2Desk совместимы с любым программным обеспечением.
4. Виртуальные серверы: для расширения вашей инфраструктуры и снижения нагрузки.
Мы предлагаем 3 схемы развертывания In-House:
Минимальная: для 1000-2000 обращений в сутки. Такой тип подходит для первого подключения, чтобы определить нагрузку на сервера.
Средняя: увеличенная производительность и повышенная безопасность.
Максимальная: для хранения больших объемов данных внутри локальных сетей крупных корпораций.
SaaS vs Enterprise
Для подведения итогов рассмотрим и сравним облако и Enterprise-решение.
Почему In-House более выгоден
Итоговая стоимость SaaS-решения складывается из количества операторов, подключенных мессенджеров и дополнительных опций и модулей. Оплата происходит каждый месяц, квартал или год со скидкой. В случае с On-Premise вы покупаете сервис раз и навсегда. Сравним затраты одной кредитной организации на SaaS и аналог Enterprise-решения:
Наглядно видно, что начальный взнос за облако гораздо ниже, чем разовая покупка In-House. Если сравнить затраты в долгосрочном периоде, то SaaS-решение за 5 лет обойдется в 1 800 000 рублей. И, хотя On-Premise-решение изначально требует большого вложения денег, спустя годы такое приобретение окупится. На графике ниже мы наглядно показали, как будут выглядеть суммарные затраты на облако и In-House.
Заключение
Внедрение Enterprise — решение, требующее разового вложения денег, в отличие от SaaS. Необходимо закупить необходимое оборудование, привлечь разработчиков, внедрить инфраструктуру. Но так вы можете быть спокойным за безопасность ваших данных, контролировать скорость и мощность работы, кастомизировать сервис под свои задачи. К тому же внедрение чат-центра сократит расходы на другие бизнес-процессы.
Определите, какое решение подходит вашему бизнесу и действуйте. Вам нужна помощь? Напишите Chat2Desk через виджет в углу экрана и мы обязательно вас проконсультируем.
