Зионек

Что выбрать — Битрикс24-«облако» или 1СБитрикс24-«коробку»?

Wed, 09 Aug 2023 12:28:00 +0300

Обновление от сентября 2023 года: с 01.09.2023 переход из облачного Битрикс24 в коробочный 1С-Битрикс24 используя бэкап от компании 1С-Битрикс невозможно, теперь только через интеграционные решения (что пока что не позволяет перенести всё).

Когда предприниматель, далёкий от IT, впервые внедряет в своём бизнесе CRM систему Битрикс или переходит на неё с другой CRM, перед ним — владельцем будущей системы — обязательно возникает вопрос: покупать лицензию на «облачную» или на «коробочную» версию Битрикс24? Цель этой статьи — быстро рассмотреть, что на самом деле означают эти термины и вникнуть в главные преимущества одной и другой версии. Поняв эти базовые отличия, вы легко сможете ответить себе на вопрос о том, какая же версия вам нужна.

Эта статья подготовлена компанией Зионек. Мы внедряем CRM, разрабатываем корпоративные порталы, Интернет-магазины и сложные высоконагруженные системы.

Почему выбор между «коробкой» и «облаком» важен (и почему он непрост)

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

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

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

Прежде, чем мы пойдём дальше — что такое «Битрикс» вообще?

Компания 1С-Битрикс называет свой продукт «набором решений для бизнеса», который «объединяет различные инструменты, такие как обмен сообщениями, телефонию, CRM, управление задачами и проектами в единую рабочую среду для вашего бизнеса». Это определение, хотя и верное, запутывает техническую сторону вопроса — что это физически такое, «набор решений, объединяющий инструменты в единую среду»? О чём мы вообще говорим?

На самом деле, надо осознать, что Битрикс24 — это просто-напросто компьютерная программа. Она имеет огромные возможности, прекрасно подходит для обеспечения бизнес-процессов как в небольших компаниях, так и в крупных корпорациях, но технически это просто очень большая программа для компьютера, а не что-то необъятно-магическое. И как любая другая компьютерная программа, Битрикс24 требует какого-то компьютера, на котором будет работать и где будет храниться и она сама (исполняемый код), и те данные, которые будут создаваться и модифицироваться пользователями каждый рабочий день.

Пользователи, как правило, работают с Битрикс через браузеры на своих устройствах (настольных компьютерах, ноутбуках, планшетах и телефонах). Но где работает сама программа Битрикс? Ответ на этот вопрос — это первое главное различие между облачной и коробочной версией.

Первое главное отличие: на чьём компьютере запущена ваша копия Битрикс24?

Так вот, чтобы ответить на вопрос о том, на чьём компьютере располагается и работает ваша копия Битрикс24 — компания-разработчик этой программы выбрала устоявшиеся термины «облачная версия» и «коробочная версия», которые, к сожалению, часто непонятны предпринимателям, если их работа не связана с IT. Разработчикам смысл этих терминов понятен, а вот клиентам — не всегда.

Когда мы говорим «облачная версия», это значит, что вы арендуете доступ к хостингу (т.е. к компьютеру в Интернете) с уже предустановленной стандартной версией Битрикс24. Такой хостинг на всей планете продаёт только компания 1С-Битрикс24 (разработчик самой системы), и когда вы оплачиваете вашу подписку на доступ к облачной версии — вы одновременно платите за две вещи: за использование их программы, и за хостинг, т.е. за аренду компьютера в Интернете, где эта программа установлена и где лежат ваши данные.

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

Резюмируя. Важно понять, что “коробочная версия” — это сама программа, которую вы устанавливаете на подходящий компьютер сами, и пользуетесь по своему усмотрению. “Облачную” версию уже поставили за вас, на компьютер в Интернете, и предоставили вам туда доступ. Вот и всё.

Второе главное отличие: есть ли у вас «исходный код» программы или его у вас нет?

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

Помимо модификации исходного кода, модификации могут быть внесены установкой готовых дополнительных модулей, которые подключаются через так называемые «программные интерфейсы» (API), а также создание собственных модулей. Далее — рассмотрим детально возможности модификации той и другой версии.

Особенности «коробочной» версии с точки зрения вашего доступа к исходному коду программы и возможностям модификации

Коробочная версия поставляется в исходном коде (и, как мы помним, работает на вашем собственном сервере или хостинге). Это означает, что вы можете нанять разработчиков и заказать им любые нужные вам изменения и расширить функциональность любым нужным вам образом, чтобы подстроить систему под нужды вашей компании. При этом, вы можете изменить абсолютно всё — от визуального дизайна до структур базы данных. Вы можете настроить обмен данными с любыми другими программами и системами, которые используете — другими словами, возможна интеграция с чем угодно. Технических препятствий нет никаких.
Для коробочной версии имеется два маркетплейса готовых приложений (т.е. готовых модулей, которыми вы можете расширить функционал 1С-Битрикс24).
У коробочной версии имеется два разных API (программных интерфейса) для разработки и подключения собственных модулей: так называемые REST API и Bitrix Framework
И наконец, вы можете непосредственно модифицировать исходный код. При этом важно отметить, что любые изменения необходимо делать осознанно и в соответствии с документацией и рекомендациями 1С-Битрикс24, для того, чтобы сохранить возможность производить обновление программы новыми версиями модулей от 1С-Битрикс24.

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

Облачная версия установлена на серверах компании 1С-Битрикс, и никто извне не может вносить изменения в исходный код.
Для облачной версии доступен только один маркетплейс приложений (вместо двух, доступных для «коробки»).
Для облачной версии доступен только один программный интерфейс, REST API (вместо двух, доступных для «коробки»).
Таким образом, если нужные вам настройки и приложения есть, и делают всё, что вам нужно — отлично. Если там нет чего-то нужного, то единственная надежда, что это всё-таки можно реализовать в рамках возможностей REST API (и тогда вы нанимаете разработчиков и они создают для вас соответствующий модуль). Если же такая функциональность в принципе невозможна в онлайн-приложении, то вам придётся жить без неё — или переходить на коробочную версию.

Что следует из двух главных отличий облачной и коробочной версий.

Итак, фундаментальных отличий у облачной и «коробочной» версий только два: кто контролирует компьютер (сервер), на котором работает Битрикс, и может ли ваша команда вносить в Битрикс любые изменения.

Коробочная версия: сервер контролируете вы, и вы можете вносить изменения.
Облачная версия: сервер контролирует компания 1С-Битрикс, и вы не можете вносить изменения.

Посмотрим на несколько примеров. Что эти различия означают для реальных компаний в реальном мире?

Примеры: законодательство, доступ к базам данных, резервные копии, доступность сервиса.

Если в вашей индустрии, законодательство требует какого-то особого способа хранения ваших данных, или хранилище должно быть в каком-то особом месте — то, чтобы выполнить эти требования, вам понадобится «коробочная» версия, которую вы установите на правильный сертифицированный сервер, расположенный в правильном месте. При необходимости, вы сможете переместить ваши данные куда-то ещё, столько раз, сколько окажется нужным. В случае «облачной» версии, вы не контролируете местонахождение ваших данных.
Если вам необходимо, чтобы ваш портал и доступ к базам данных был физически возможен только изнутри вашей организации, то очевидно, вам нужна «коробочная» версия, установленная на вашем же сервере, т.к. «облачная» версия всегда доступна из любой точки интернета.
Если вам необходима интеграция с информационными системами вашей организации и базами данных , которые не доступны «снаружи» вашей корпоративной сети, очевидно, что вам понадобится коробочная версия. Пример — медицинская организация, которая нуждается в интеграции медицинской информационной системы и CRM Битрикс24.
В облачной версии, резервные копии делаются автоматически, без вашего участия; есть основания надеяться, что на серверах 1С-Битрикс24 всё сделано правильно и резервные копии будут вам доступны, если они понадобятся. В случае же «коробочной» версии, ваша команда должна обеспечить правильную настройку и организацию полноценного резервного копирования, с хранением копий как локально в компании, так и где-то на удалённых серверах (на случай пожара или иной беды, которая может разрушить вашу локальную резервную копию).
В целом, в случае коробочной версии, на вашей команде лежит вся ответственность за то, чтобы ваша CRM система работала без перебоев, чтобы данные были надежно защищены как от попыток взлома, так и от непредвиденных аварий или стихийных бедствий, и чтобы ваш сервер был быстр и доступен. В случае облачной версии, вся эта ответственность лежит на хостинге 1С-Битрикс24.

А что по деньгам? Какая версия выгоднее?

Битрикс24 существует в нескольких разных модификациях, отличающихся доступным функционалом на разных тарифных планах (то есть, разные тарифы различаются не только разрешенным количеством пользователей, но и доступными для этих пользователей функциями), и поэтому сравнить тарифы — совсем не просто. Однако, если мы не будем учитывать ваших затрат на IT-команду, коробочная версия всегда будет выгоднее, чем облачная, хотя это и не сразу очевидно.

Цена за первый год

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

«Коробочная» версия (редакция Корпоративный портал, 100 пользователей) в первый год стоит 200 тыр.руб, и вы должны прибавить стоимость хостинга около 40тыс.руб/год (итого 240 тыс.руб)
«Облачная» версия на тарифе Профессиональный на 100 пользователей обойдется вам в 135 тыс.руб. Экономия на облаке! Однако, давайте посмотрим, что будет дальше. Вы покупаете эту систему не на один год.

Цена за обновления

Что будет во второй и следующие годы работы? Тариф облачной версии остаётся неизменным — вы платите 100%, а вот лицензия на обновление коробочной версии обходится только в 25% от первоначальной стоимости. Это значит, что самое позднее, с третьего-четвертого года, ваша коробочная версия будет значительно дешевле, чем облачная, и при этом она имеет более широкий функционал, с возможностью любых модификаций, расширений и интеграций.

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

Преимущества облачной версии

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

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

Перенос данных туда-обратно: как переехать из облачной версии на коробочную (и назад)

Изначально, «сразу из коробки», коробочная версия имеет ту же структуру данных, что и облачная. По этой причине, переезд из облачной версии на коробочную хорошо документирован на сайте Битрикс и является достаточно рутинной процедурой (хотя это и непросто технически).

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

Перенос данных из других CRM в Битрикс24 (и из Битрикс24 в другие CRM)

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

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

И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!

Подробнее...

Мы говорим “Битрикс”, подразумеваем… что? Шпаргалка по официальным названиям разных версий Битрикс

Fri, 12 May 2023 12:21:07 +0300

Ваша компания, далёкая от IT, внедряет у себя CRM, и ваш подрядчик говорит: «Вам нужна лицензия на 1С-Битрикс24. Именно с приставкой “1С”. Без “1С” не подойдёт». Что он имеет в виду и почему не подойдёт?

Эта статья поможет быстро разобраться, что означает приставка «1С» в 1С-Битрикс24 — и вообще, какие технические различия скрываются за различными названиями версий Битрикс.

Это статья подготовлена компанией Зионек. Мы внедряем CRM, разрабатываем корпоративные порталы, Интернет-магазины и сложные высоконагруженные системы.

Обращайтесь к нам в Зионек с самыми сложными задачами по интеграции и автоматизации бизнес-процессов

Что такое 1С и что такое Битрикс? Краткая история изменения названий.

Когда-то в прошлом, две совершенно разные компании развивали два совершенно разных семейства продуктов.

Фирма 1С давала своим продуктам названия, которые начинались с «1С» — «1С:Предприятие», «1С:Бухгалтерия» и так далее.

Компания Битрикс продавала систему для создания сайтов и управления контентом (CMS) и тоже включила название своей компании в название продукта: «Битрикс: Управление Сайтом».

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

Три главных продукта Битрикс

Итак, несмотря на наличие 1С в названии, семейство продуктов Битрикс полностью отличается от продуктов 1С:Предприятие. Их развивают, по сути, разные компании, точно так же, как они это делали изначально. Главных продуктов Битрикс три:

1С-Битрикс: Управление Сайтом (БУС) — система для создания сайтов и управления ими (CMS, Content Management System — система управления контентом). Не включает в себя CRM.

Битрикс24 — облачный сервис для управления бизнесом (CRM, Customer Relationship Management — система управления отношениями с клиентами).

1С-Битрикс24 — коробочная версия Битрикс24, включает в себя все возможности 1С-Битрикс: Управление Сайтом.

В чём заключается разница между облачной версией Битрикс24 и коробочной версией — тема отдельной статьи. Именно эту разницу и имеет в виду интегратор, когда говорит вам, что нужна именно версия «1С-Битрикс24», и что версия без приставки «1С» не годится.

Очень похожие названия, но очень разные продукты

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

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

Подробнее...

Система управления, планирования и исполнения закупок для государственного университета в 1С-Битрикс24

Sat, 08 Apr 2023 12:15:20 +0300

Руководство Государственного социально-гуманитарного университета в Коломне (ГСГУ) обратилось в Зионек за помощью в автоматизации своих процессов, связанных с закупками в CRM 1С-Битрикс24.

Введение

ГСГУ — крупное образовательное учреждение, входящее в топ-100 ВУЗов России, с двумя дополнительными филиалами в Московской области помимо основного кампуса. Здесь ежегодно обучаются более 4 тыс. студентов по 30 направлениям высшего образования и магистратуры.

Это кейс компании Зионек. Мы внедряем CRM, разрабатываем корпоративные порталы, Интернет-магазины и сложные высоконагруженные системы.

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

Процесс принятия решений о закупках

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

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

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

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

Исполнение бюджета. Теперь у ВУЗа есть полностью сформированный и согласованный бюджет на следующий год. И когда следующий год наступает, ВУЗ работает в рамках этого бюджета, исполняет его — со всеми сроками, со стоимостями и так далее.

Детали реализации, разработка специального таблично-древовидного интерфейса для Битрикс

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

Внешний вид бюджета университета в таблично-иерархическом интерфейсе для Битрикс, созданного специально для ГСГУ. Из этого интерфейса можно сразу создавать закупки, отмечая галочками нужные позиции. Разработка: Зионек. (Все данные тестовые, к реальному бюджету ГСГУ не имеют никакого отношения)

Процесс создания закупок

Закупки, в процессе исполнения бюджета, создаются там же, прямо из этого созданного нами Битрикс-интерфейса: пользователи просто отмечают галочками нужные позиции (см. скриншот ниже). При этом, разработанные нами процессы CRM автоматически разбивают все заказы на отдельные позиции и распределяют эти позиции по проректорам и другим лицам, отвечающим за закупку соответствующих товаров. Другими словами, если некий сотрудник включил в один заказ товары разных категорий, за закупку которых отвечают разные люди (например, компьютеры и электрические лампочки), наша система автоматически поймёт, к какому проректору какой товар относится и сама создаст для каждого проректора заявки на закупку.

Внешний вид формы закупки, созданной напрямую из таблично-древовидного интерфейса бюджета. Этот интерфейс закупок также создан нами специально для ГСГУ. Разработка: Зионек. (Все данные тестовые, к реальному бюджету ГСГУ не имеют никакого отношения)

Разгруппировка товаров с разными ценами и их корректировка

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

На этом скриншоте видно, что мы исправили неверную цену группы. Интерфейс закупок для ГСГУ. Разработка: Зионек. (Все данные тестовые, к реальному бюджету ГСГУ не имеют никакого отношения)

На этом скриншоте, мы разгруппировали разные товары и разнесли их по двум новым группам. Интерфейс закупок для ГСГУ. Разработка: Зионек. (Все данные тестовые, к реальному бюджету ГСГУ не имеют никакого отношения)

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

Заключение

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

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

Подробнее...

Внедрение CRM и тесная интеграция МИС «Инфоклиника» с 1С-Битрикс24 в многопрофильной клинике реабилитации

Mon, 20 Mar 2023 11:57:00 +0300

Здание Реабилитационной клиники в Хамовниках расположено на ул. Ефремова, 12, корп.2 в Москве.

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

Клиника была открыта в 2016 году под руководством мирового эксперта и Заслуженного врача РФ Федина Анатолия Ивановича – профессора, доктора медицинских наук, врача-невролога.

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

Новейший магнитно-резонансный томограф (МРТ) Philips мощностью 1,5 Тесла (МРТ-сканер). Клиника реабилитации в Хамовниках

Сейчас в клинике работают более 50 врачей (более 25 специальностей). Основные направления работы: ортопедия, неврология, кардиореабилитация, восстановление нервной и сердечно-сосудистой систем. В клинике работают врачи с многолетним опытом, ведущие специалисты-реабилитологи, кандидаты и доктора наук.

Обращение клиента, его нужды и главные задачи

Руководство клиники обратилось в Зионек для помощи с решением целого ряда задач.

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

Рабочий процесс в Зионек

Выбор продукта

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

Главный приоритет: эффективная коммуникация с пациентами.

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

Наше решение заключалось в том, чтобы автоматически выбирать канал общения с клиентом и приоритизировать наиболее экономичный для клиники, при этом эффективный для поддержания связи с клиентом. Автоматически выбирается канал связи: CRM проверяет, есть ли у клиента Телеграм, и если есть — сообщения отправляются туда. Если Телеграма нет, то мы делаем проверку Whatsapp, и если есть — то мы отправляем сообщения туда. Если нет ни того, ни другого, то мы отправляем СМС-сообщение. Это позволяет вести эффективное оповещение пациентов и одновременно снизить стоимость отправки сообщений.

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

Наши собственные CRM-формы для подтверждения записи и сбора обратной связи

Стандартные CRM-формы, встроенные в 1С-Битрикс24, оказались неудовлетворительными для этого проекта ни с точки зрения дизайна, ни с точки зрения функционала. По этой причине, мы разработали наши собственные формы подтверждения визита и формы для сбора обратной связи, и теперь они одновременно привлекательные и функциональные.

Форма для подтверждения записи в клинику. Дизайн Зионек

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

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

Опрос удовлетворенности пациентов.

Для клиники, разумеется, важно собирать обратную связь от пациентов. Форма анкеты и её особое поведение — разработаны нами специально для этого клиента.

Форма обратной связи (никакой рейтинг пока не выбран, поля для ввода комментария нет). Разработка и дизайн Зионек

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

Форма обратной связи от пациентов медицинской клиники. Выбрана низкая оценка, и форма автоматически запрашивает дополнительную информацию. Разработка и дизайн Зионек

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

Интеграция Медицинской Информационной Системы (МИС) «Инфоклиника» с 1С-Битрикс24 с полным соблюдением 152-ФЗ

Собственный модуль Зионек для интеграции МИС «Инфоклиника» и 1С-Битрикс24

В клинике используется Медицинская Информационная Система (МИС) “Инфоклиника”, и перед нами стояла задача интегрировать базу данных МИС с CRM нашего клиента, полностью и на всех этапах соблюдая при этом требования Федерального Закона «О персональных данных», 152-ФЗ. 1С-Битрикс24 не имеет никакого модуля для такой интеграции, также как его не имеет и МИС «Инфоклиника», и поэтому мы разработали наш собственный резидентный программный компонент для Windows, который периодически самостоятельно (по расписанию) запускается в фоновом режиме, прочитывает напрямую из базы данных нужную информацию и добавляет её в CRM.

Интерфейс резидентного модуля интеграции медицинской информационной системы (МИС) «Инфоклиника» и 1С-Битрикс24. Модуль читает обезличенные данные напрямую из БД МИС и добавляет эти данные в CRM 1С-Битрикс24. Разработка Зионек

Хранение и обработка информации соответствует 152-ФЗ

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

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

У колл-центра был (и есть) свой ограниченный доступ в Инфоклинику, где работники колл-центра вели и продолжают вести запись пациентов, однако теперь, обзвоны пациентов уже делаются из 1С-Битрикс24.

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

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

Обеспечение эффективной внутренней коммуникации между специалистами клиники

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

Итоги

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

Мы осуществили тесную интеграцию между 1С-Битрикс24 и медицинской информационной системой (МИС) «Инфоклиника». Для этого мы разработали наш собственный резидентный модуль для Windows, обойдя тем самым функциональные ограничения существующих систем. Теперь все необходимые данные могут видеть и обрабатывать менеджеры Клиники, и эти данные доступны для дальнейшей автоматизации внутри CRM. При этом, разумеется, полностью и на всех этапах соблюдается Федеральный Закон «О персональных данных» № 152-ФЗ.

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

Один из залов физиотерапии в Клинике реабилитации в Хамовниках. Специальные панели на стенах в большом зале обеспечивают уменьшение звуковых отражений (эха) и более комфортное пребывание пациентов на процедурах.

Подробнее...

Что делать, когда Лебедь, Рак и Щука задумали писать ТЗ? Как разработчик может им помочь?

Wed, 08 Mar 2023 11:51:00 +0300

Зачем заказчику ТЗ? Для чего вообще разрабатывать ТЗ и какая выгода заказчику от того, что оно правильно написано? Что сделать, чтобы оно получилось именно таким — правильно составленным и полезным?

Давайте начнём с конца. Как правильно.

Техническое задание и успех разработки

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

Однако, что такое успех?

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

Для того, чтобы достичь этого успеха — исполнителю/разработчику нужно очень точно знать, в очень конкретных и чётких технических терминах, какие конкретно работы ему предстоит осуществить.

А вот тогда, когда исполнителю/разработчику это на самом деле неясно, и новые задачи вдруг неожиданно всплывают в процессе выполнения работ — вот тогда-то и оказываются сроки — сорванными, а затраты превышают запланированный бюджет.

И вот выходит на сцену Техническое Задание.

Техническое Задание — чёткий и детальный технический документ, полностью описывающий все те работы, которые предстоит осуществить исполнителю, чтобы система получилась именно такой, какая нужна заказчику. При этом, оно написано так, что понятно и заказчику, и техническому специалисту. Одновременно ТЗ показывает заказчику, сколько все эти работы будут стоить.

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

Откуда же берётся такое ТЗ? Кто его пишет так, чтобы оно получилось одновременно и совершенно конкретным, детальным, и пригодным к тому, чтобы разработчик мог немедленно начать его реализовывать, и при этом, чтобы заказчик прекрасно видел и понимал, какая система у него будет?

Всё просто: такое ТЗ может составить, и должен составить — сам исполнитель.

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

Функциональные требования для разработки ТЗ

Для того, чтобы исполнитель мог составить ТЗ, нужно, чтобы заказчик рассказал ему, что собственно требуется от будущей системы. Эта информация называется «Функциональные Требования».

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

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

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

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

Созданное таким образом ТЗ становится далее частью договора на дальнейшую разработку и основой для расчета сметы на работы.

Что же пошло не так?

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

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

Источник проблемы, скорее всего, в том, что специальный термин «Техническое Задание» (обладающий очень узким и конкретным смыслом), оказался слишком сильно похож на обычное бытовое слово «задание» — а оно, в свою очередь, в быту ничем не отличается от слова «задача». Задача — это и «поставить задачу в CRM», это и записаться к врачу, это и школьная задача на умножение, с которой ребёнок просит ему помочь.

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

В результате, слово «задание» с детства стало в нашей жизни настолько бытовым и нечётким, что уже выросшие взрослые, ставшие заказчиками различных работ, предполагают, что если просто «подробно и детально описать, что нам нужно» — то это описание и будет являться Техническим Заданием для исполнителя (разработчика). «Мы же, в конце концов, описываем серьёзные технические вещи, а не рецепт пирога, — думает заказчик, — значит, у нас получилось Техническое Задание». Увы, это не так.

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

Разные разработчики создают разные ТЗ — как выбрать?

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

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

Уровень ТЗ соответствует уровню разработчика

Откуда берётся эта разница в качестве ТЗ (и соответственно, в качестве будущей системы)?

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

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

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

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

Как мы разрабатываем ТЗ в Зионек

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

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

Подробно о нашем подходе мы написали в следующих статьях:

Подробнее...

Срочная миграция в Битрикс24 из зарубежной CRM-системы для GoodsForecast

Wed, 01 Mar 2023 11:38:00 +0300

Быстрая разработка мигратора CRM для переноса данных в Битрикс24 из зарубежной системы в чрезвычайно сжатые сроки

Введение

Компания GoodsForecast с 2004 года занимается разработкой IT продуктов на базе искусственного интеллекта для решения задач, связанных с прогнозированием спроса, управлением цепями поставок, снижением издержек, планированием продаж и повышением эффективности производств, на рынке Российской Федерации и стран СНГ.

Среди клиентов компании - пивоваренная компания «Балтика», компания «Филип Моррис», корпорация ТЕХНОНИКОЛЬ, группа «Черкизово», сети супермаркетов «Верный» и «Перекресток», группа компаний «О’КЕЙ» и другие крупные производственные и торговые предприятия из производственного сектора, ритейла, логистики, сельского хозяйства.

Обращение клиента и наши задачи

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

Рабочий процесс в Зионек

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

Пример интерфейса программного продукта компании Goodsforecast: циклы поставок, прогноз out-of-stock событий

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

Результаты для клиента

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

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

Подробнее...

Наша замена Selenium и другой инструментарий. Сложная разработка без брифов, часть 3

Sun, 26 Feb 2023 11:29:08 +0300

Заключительная статья о том, как мы в Зионек работаем без брифов — и в результате экономим клиентам время и деньги

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

Тестирование как важная часть нашего процесса

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

Наша замена Selenium: браузер Hat для тестирования web-приложений

Качественные инструменты для тестирования для нас чрезвычайно важны, и поэтому мы серьёзно вложились в разработку качественного решения для тестирования, на которое невозможно наложить санкции и заблокировать его использование. Это браузер Hat — open-source разработка Евгения Сомова, Ведущего тестировщика в Зионек, которая по сути заменяет Селениум (Selenium) — браузер со встроенной технологией автоматизации тестирования Web приложений. Наша компания поддерживает этот проект, и в результате, мы и сами имеем возможность использовать качественный инструмент, и мы также видим ценность в том, чтобы этот инструмент был с открытым кодом и его могло использовать и развивать максимально широкое сообщество программистов.

Интерфейсные окна браузера Hat

Особенность браузера Hat в том, что автотесты напрямую выполняются в браузере — без Selenium и WebDriver.

Встроенный фреймворк HatFramework содержит достаточное количество методов, необходимых для выполнения основных задач автоматизации тестирования. Для описания скриптов автотестов используется язык программирования C# и встроенный редактор кода. Также в качестве редактора можно воспользоваться Visual Studio. Удобный интерфейс браузера отображает все шаги выполнения теста с подробным описанием событий. Результаты проверки формируются в отчет и отправляются на указанную почту. Запуск автотестов возможен из командной строки операционной системы Windows — это пригодится при использовании автотестов в популярных средствах непрерывной интеграции, таких как Jenkins, TeamCity, GitLab CI/CD.

Браузер Hat на github: https://github.com/SomovStudio/Hat

Система контроля версий

Другой наш важнейший инструмент — система контроля версий. Мы используем везде git — на сегодняшний день, это самая современная система контроля версий, всё остальное практически устарело.

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

Мы же используем git на 100% — мы всё разрабатываем, показываем клиенту, и всё делаем через систему контроля версий. А потом, когда клиентам устанавливаем «боевую» версию, мы это также делаем через git. У нас есть некий стенд — это одновременно пространство для наших тестов и то, как мы показываем клиенту текущую работу. Соответственно, после разворачивания на системе клиента «боевой» версии, дальнейшее взаимодействие идёт таким же образом — что-то мы показываем на тесте, и соответственно, когда клиент это принимает, мы это перекидываем с помощью git на текущую «боевую» версию («прод» в терминологии разработчиков); и, так как мы используем git, то мы не можем потерять какие-то изменения, которые внесли, а в случае чего — можем быстро откатиться назад.

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

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

Мы используем миграции для баз данных

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

Мы используем собственные модули

Например, когда мы разворачиваем корпоративные порталы, нам часто помогает при настройке почты наш собственный модуль «Внешний SMTP. Отправка почты из коробочного 1C-Битрикс24 без боли и кода».

Благодаря этому модулю, отправка писем в коробочной версии работает так же, как в Облачном Битрикс24: вы просто создаёте ящики (столько ящиков, сколько вам нужно) в разделе «Почта» в CRM и спокойно пользуетесь, без дополнительных настроек. Модуль работает в почтовом клиенте CRM, в контактах, лидах, сделках и т.д.

Модуль уже настроен на работу с почтой Mail.RU, Яндекс.Почта и Google Mail, но если вам нужно добавить свой SMTP сервер, то это легко сделать в настройках. Это чрезвычайно удобный компонент, полностью снимающий головную боль при настройке почты в коробочной версии 1С-Битрикс24. Всем горячо рекомендую, вот ссылка: https://marketplace.1c-bitrix.ru/solutions/zionec.smtp/

Мы задаём технические вопросы правильным людям

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

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

Предыдущие статьи этой серии: Как мы в Зионек выявляем потребности клиента — без брифов и головной боли

Сложная разработка — без брифов (часть 1). Как это возможно и зачем отказываться от брифования клиента при внедрении CRM

Как отказаться от брифов в веб-разработке и какая от этого польза. (Сложная разработка без брифов, часть 2)

Мы часто берёмся за большие и сложные проекты, но умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!

Подробнее...

Как отказаться от брифов в веб-разработке и какая от этого польза. (Сложная разработка без брифов, часть 2)

Tue, 14 Feb 2023 11:21:14 +0300

Продолжение рассказа о том, как мы в Зионек выявляем потребности клиента — без брифов и головной боли

Это вторая статья из серии, в которой мы подробно разбираем процесс, принятый в Зионек для выявления потребностей клиента. Мы отказались от заполнения брифов, и это экономит массу времени заказчиков, что весьма их радует. Также, сильно повышается скорость и качество разработки, и это радует заказчиков ещё сильнее. При этом, у нас ни разу не было проблем с приёмкой работ; никогда не было случая, чтобы клиент получил не то, что он «на самом деле имел в виду». Заказчик получает именно то, что хочет, и 100% наших заказчиков остаются довольны результатом. Всё это — без брифов. Нет, это не чёрная магия; в этих статьях мы подробно разбираем наши методы и как нам это удаётся.

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

Но для начала вспомним, чем плохи брифы.

Что не так с брифом: почему брифы не работают

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

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

Это одна из важных причин (однако, не единственная), из-за которых мы отказались от брифов. С тех пор мы никаких брифов не заполняем, и никаких брифов клиентам не высылаем.

Что же мы делаем вместо этого?

Выявление потребностей клиента без брифов. Веб-сайты и Интернет-магазины (там, где требуется визуальный дизайн).

Первый шаг — установочная встреча

Напомню, что мы всё делаем несколько иначе в случаях внедрения CRM — то есть там, где не нужен визуальный дизайн (см. предыдущую статью). Тогда же, когда визуальный дизайн как раз нужен, на первой установочной встрече с клиентом мы просим примеры “что нравится” — то есть, какие сайты похожи на то, что заказчик хотел бы у себя реализовать. И конечно, мы внимательно слушаем, что заказчик хочет рассказать о своих задачах и своём видении. Это прекрасно работает в онлайне, и при этом мы ведём запись всей встречи, чтобы мы могли пересмотреть всё снова.

Второй шаг — сразу дизайн, созвоны и проработка

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

Все встречи автоматически документируются

Тут есть несколько важных аспектов.

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

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

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

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

На всех этапах у нас присутствует тестировщик

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

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

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

На всех встречах присутствуют верстальщики и разработчики

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

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

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

Важная разновидность плохого дизайна: неоправданно дорогие решения

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

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

Разумеется, мы делаем не только Интернет-магазины, но бизнес-цель есть у любого сайта и у любой страницы, и всегда нужно, чтобы будущие посетители сайта — клиенты нашего заказчика — не отвлекались от этой цели; для того, чтобы к ней привести, используются разные механики пользовательского интерфейса и взаимодействия с пользователем (UI/UX), и мы выбираем те, которые наиболее эффективны.

Как мы пришли к такому процессу

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

Сначала мы писали вордовские документы, и у нас были брифы, как у всех. Мы видели, как с ними плохо, и искали решение.

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

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

Что думают клиенты о работе без брифов

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

IT-команда клиента

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

Однако, некоторые компании хотят установку и настройку делать сами, и в этом случае мы консультируем их администраторов — как это сделать, какие правильные настройки внести и так далее.

Дополнительные технические аспекты эффективной работы без брифов

Помимо нашего нестандартного брифования, у нашего процесса есть ещё несколько особенностей, повышающих скорость и качество разработки. Мы их вынесли в отдельную статью: “Наша замена Selenium и другой инструментарий. Сложная разработка без брифов, часть 3”

Подробнее...

Сложная разработка — без брифов (часть 1). Как это возможно и зачем отказываться от брифования клиента при внедрении CRM

Sun, 12 Feb 2023 10:38:00 +0300

Как мы в Зионек выявляем потребности клиента — без брифов и головной боли

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

Два направления нашей работы: CRM и сложные сайты

У нас в Зионек есть два основных направления работы (или если угодно, две темы) — с одной стороны, мы внедряем CRM, что не требует особого визуального дизайна; и с другой стороны, мы разрабатываем Интернет-магазины и корпоративные порталы, где визуальный дизайн как раз нужен. Наш подход в этих случаях различается. В данной статье мы расскажем о том, как у нас устроена работа без брифов на CRM-направлении.

Выявление потребностей клиента при внедрении и кастомизации CRM

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

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

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

Проблемы с брифом: что происходит, если используется бриф

Обычно, если вы используете бриф, то получается так: на первой стадии, вы присылаете клиенту этот огромный word-документ, и задача клиента — его заполнить. Это сама по себе большая и долгая работа, но клиент её делает, он думает, что это необходимо, и заполняет этот самый бриф.

Конечно, клиентам совсем не нравится заполнять брифы, это 100% так, никакого открытия тут нет — все разработчики прекрасно знают, что клиенты не любят заполнять брифы!

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

Поэтому мы в Зионек никаких брифов не заполняем, никаких брифов клиентам не высылаем.

Наш подход к “брифованию без брифов” при внедрении и кастомизации CRM

У нас для CRM есть своя собственная разработанная форма ТЗ, которая вовсе не огромный word-документ на 300 страниц, а excel-файл с вложенными листами, в котором клиент визуально понимает, как будет работать его система, где будут и какие автоматизации; там обозначены обязательные поля и видно, что будет происходить с коммуникациями; и так далее. По сути, этот документ — это наше ТЗ, у которого наш особый дизайн. Очень важно тут то, что его заполняет не клиент; этот документ заполняет наш специалист, во время интервью с клиентом — заполняет в реальном времени, отталкиваясь от того, что говорит клиент, что он рассказывает о своём бизнесе, о своих процессах и своих потребностях.

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

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

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

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

Ещё одна важная сторона нашего процесса — экономия времени клиента

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

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

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

Что думают клиенты о работе без брифов

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

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

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

Отказ от брифов при разработке сайтов, корпоративных порталов и Интернет-магазинов

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

Дополнительные технические аспекты эффективной работы без брифов.

Помимо нашего нестандартного, но очень эффективного брифования, у нашего процесса есть ещё несколько особенностей, повышающих скорость и качество нашей разработки. Мы их вынесли в отдельную статью: “Отказ от брифов для сложной разработки (часть 3): Инструменты и их использование”

">#000000;">
И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/ и вот наша страница контактов. Пишите, звоните — мы вас поймём, проконсультируем, поможем!

Подробнее...

Внедрение CRM, разработка корпоративного портала и Интернет-магазина в ЭТП «Микрохирургия глаза» им. Фёдорова

Thu, 02 Feb 2023 10:38:00 +0300

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

Введение

Экспериментально-техническое производство (ЭТП) «Микрохирургия глаза» является филиалом Федерального государственного автономного учреждения «Национальный медицинский исследовательский центр» межотраслевой научно-технический комплекс «Микрохирургия глаза» имени академика С.Н.Фёдорова» Министерства здравоохранения Российской Федерации.

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

Хирург-офтальмолог во время лабораторного тренинга по применению передовой продукции (расходников и инструментов) производства ЭТП «Микрохирургия глаза» им. Н.С.Федорова

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

Обращение клиента и наши задачи

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

В числе задач на первом этапе были следующие:

· Автоматизировать процессы коммерческого отдела связанные с продажами, производимой предприятием продукции.

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

· Автоматизировать процесс согласования и исполнения заявок на закупку от сотрудников.

· Реализовать другие внутренние процессы предприятия на портале.

На следующем этапе в наши задачи входила разработка Интернет-магазина компании, тесно привязанного к CRM.

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

Руководство организации предъявляет жёсткие требования к полной безопасности информации и к контролю над всеми процессами. По этой причине, с учётом задач клиента, мы выбрали коробочную версию 1C-Битрикс24 как платформу для реализации CRM, портала и Интернет-магазина.

Первый этап. Создание корпоративного портала и внедрение CRM-системы для автоматизации отдела продаж

Особенности проекта, встреченные сложности и последовательность выполнения работ

Внедрение было решено разделить на два подэтапа:

1.1. Настройка и внедрение CRM для Коммерческого отдела.

1.2. Создание процессов для заявок и разработка документооборота, в том числе реестра договоров, внедрение портала для всего предприятия.

Первый подэтап: Настройка и внедрение CRM для Коммерческого отдела

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

Мы настроили три воронки продаж в CRM, стадии отслеживания счетов и коммерческих предложений.

При настройке почты, нам сильно облегчил работу модуль «Внешний SMTP. Отправка почты из коробочного 1C-Битрикс24 без боли и кода», разработанный нашей компанией. Благодаря этому модулю, отправка писем в коробочной версии работает так же, как в Облачном Битрикс24: вы просто создаёте ящики (да, можно несколько) в разделе «Почта» в CRM и спокойно пользуетесь, без дополнительных настроек. Модуль работает в почтовом клиенте CRM, в контактах, лидах, сделках и т.д. Модуль уже настроен на работу с почтой Mail.RU, Яндекс.Почта и Google Mail, но если вам нужно добавить свой SMTP сервер, то это легко сделать в настройках. Это чрезвычайно удобный компонент, полностью снимающий головную боль при настройке почты в коробочной версии 1С-Битрикс24. Всем горячо рекомендую, вот ссылка: https://marketplace.1c-bitrix.ru/solutions/zionec.smtp/

Первые трудности настигли нас при работе над шаблонами документов для оформления сделок. Так как наш клиент является филиалом государственного учреждения, требования к печатным формам самые жёсткие и бескомпромиссные.

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

Второй подэтап: Создание процессов для заявок и разработка документооборота

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

Все этапы, которые должна пройти заявка в процессе согласования, мы представили в виде стадий — так же, как это работает для сделок в CRM. Таким образом, для всех сотрудников предприятия функционал работы в Битрикс24 стал выглядеть единообразно, что заметно упростило процесс обучения, внедрения и привыкания сотрудников.

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

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

Сложности, однако, нас не отпускали.

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

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

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

Хирурги-офтальмологи во время лабораторного тренинга повышения квалификации и знакомства с применением передовых технологий и инструментов. Лаборатория ЭТП «Микрохирургия глаза» им. Н.С.Федорова

Примеры использования.

Пример функционала, который используется всеми сотрудниками - это "Заявка на закупку".

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

Теперь, когда процесс согласования заявок автоматизирован, он выглядит так:

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

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

Похожий процесс работает и для исполнения заявки.

Второй этап: реализация Интернет-магазина

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

Статусы покупателей

Важным аспектом магазина ЭТП «Микрохирургия глаза» является то, что цены видны только тем посетителям (покупателям), которые предварительно зарегистрировались, попали в CRM и прошли через менеджера по продажам, который назначил им определённый статус (уровень) покупателя. И только теперь в интернет-магазине они видят цены — и это цены, соответствующие их уровню.

По мере того, как сотрудничество с тем или иным покупателем продолжается, его статус/уровень может меняться: менеджер по продажам вносит изменения в CRM и интернет-магазин автоматически отображает новые цены, согласно новому статусу. Аналогично компания может управлять ассортиментом товаров — видимость отдельных товаров также может быть настроена через уровни покупателя.

Особые условия доставки

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

Итоги: Полная автоматизация внутренних процессов, эффективный корпоративный портал, Интернет-магазин c важным специфическим функционалом

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

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

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

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

Теперь у компании есть Интернет-магазин, тесно интегрированный во внутренние процессы, его функционал отражает специфику компании и покупателей.

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

">#000000;">
То, о чём мы рассказали в этой статье — далеко не всё, что мы умеем делать. Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.

Подробнее...

Зионек

Что выбрать — Битрикс24-«облако» или 1С­Битрикс24-«коробку»?

Почему выбор между «коробкой» и «облаком» важен (и почему он непрост)

Прежде, чем мы пойдём дальше — что такое «Битрикс» вообще?

Первое главное отличие: на чьём компьютере запущена ваша копия Битрикс24?

Второе главное отличие: есть ли у вас «исходный код» программы или его у вас нет?

Особенности «коробочной» версии с точки зрения вашего доступа к исходному коду программы и возможностям модификации

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

Что следует из двух главных отличий облачной и коробочной версий.

Примеры: законодательство, доступ к базам данных, резервные копии, доступность сервиса.

А что по деньгам? Какая версия выгоднее?

Цена за первый год

Цена за обновления

Преимущества облачной версии

Перенос данных туда-обратно: как переехать из облачной версии на коробочную (и назад)

Перенос данных из других CRM в Битрикс24 (и из Битрикс24 в другие CRM)

Мы говорим “Битрикс”, подразумеваем… что? Шпаргалка по официальным названиям разных версий Битрикс

Что такое 1С и что такое Битрикс? Краткая история изменения названий.

Три главных продукта Битрикс

Система управления, планирования и исполнения закупок для государственного университета в 1С-Битрикс24

Введение

Процесс принятия решений о закупках

Детали реализации, разработка специального таблично-древовидного интерфейса для Битрикс

Процесс создания закупок

Разгруппировка товаров с разными ценами и их корректировка

Заключение

Внедрение CRM и тесная интеграция МИС «Инфоклиника» с 1С-Битрикс24 в многопрофильной клинике реабилитации

Обращение клиента, его нужды и главные задачи

Рабочий процесс в Зионек

Выбор продукта

Главный приоритет: эффективная коммуникация с пациентами.

Наши собственные CRM-формы для подтверждения записи и сбора обратной связи

Опрос удовлетворенности пациентов.

Интеграция Медицинской Информационной Системы (МИС) «Инфоклиника» с 1С-Битрикс24 с полным соблюдением 152-ФЗ

Собственный модуль Зионек для интеграции МИС «Инфоклиника» и 1С-Битрикс24

Хранение и обработка информации соответствует 152-ФЗ

Обеспечение эффективной внутренней коммуникации между специалистами клиники

Итоги

Что делать, когда Лебедь, Рак и Щука задумали писать ТЗ? Как разработчик может им помочь?

Давайте начнём с конца. Как правильно.

Техническое задание и успех разработки

Функциональные требования для разработки ТЗ

Что же пошло не так?

Разные разработчики создают разные ТЗ — как выбрать?

Уровень ТЗ соответствует уровню разработчика

Как мы разрабатываем ТЗ в Зионек

Срочная миграция в Битрикс24 из зарубежной CRM-системы для GoodsForecast

Введение

Обращение клиента и наши задачи

Рабочий процесс в Зионек

Результаты для клиента

Наша замена Selenium и другой инструментарий. Сложная разработка без брифов, часть 3

Заключительная статья о том, как мы в Зионек работаем без брифов — и в результате экономим клиентам время и деньги

Тестирование как важная часть нашего процесса

Наша замена Selenium: браузер Hat для тестирования web-приложений

Система контроля версий

Мы используем миграции для баз данных

Мы используем собственные модули

Мы задаём технические вопросы правильным людям

Предыдущие статьи этой серии: Как мы в Зионек выявляем потребности клиента — без брифов и головной боли

Как отказаться от брифов в веб-разработке и какая от этого польза. (Сложная разработка без брифов, часть 2)

Продолжение рассказа о том, как мы в Зионек выявляем потребности клиента — без брифов и головной боли

Что не так с брифом: почему брифы не работают

Выявление потребностей клиента без брифов. Веб-сайты и Интернет-магазины (там, где требуется визуальный дизайн).

Первый шаг — установочная встреча

Второй шаг — сразу дизайн, созвоны и проработка

Все встречи автоматически документируются

На всех этапах у нас присутствует тестировщик

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

На всех встречах присутствуют верстальщики и разработчики

Важная разновидность плохого дизайна: неоправданно дорогие решения

Как мы пришли к такому процессу

Что думают клиенты о работе без брифов

IT-команда клиента

Дополнительные технические аспекты эффективной работы без брифов

Сложная разработка — без брифов (часть 1). Как это возможно и зачем отказываться от брифования клиента при внедрении CRM

Как мы в Зионек выявляем потребности клиента — без брифов и головной боли

Два направления нашей работы: CRM и сложные сайты

Выявление потребностей клиента при внедрении и кастомизации CRM

Проблемы с брифом: что происходит, если используется бриф

Что выбрать — Битрикс24-«облако» или 1СБитрикс24-«коробку»?