CRM для экспонатов

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

Описываю опыт использования онлайн БД не требующей программирования (no-code, zerocod) на крупном и авральном выставочном проекте.

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

В этой статье главный герой - онлайн БД QuintaDB.

Упоминаются такие сервисы, как - Google Sheets, Access, Airtable, Zoho creator, Bubble, FileMaker, GetReport, Bitrix24, Planfix, Cerebro, SAP, Камис, АС «Музей» ГИВЦ, Zapier, Integomat.

Оглавление:

• Суть задачи
  
• Поиск решения
  
• - что удалось изучить
• - оперативное внедрение
• - подвязываем производственные процессы
• Итоги и проверка временем
  
• Интеграция
  

Я креативный и продакшн продюсер и сотрудничаю с различными продакшн компаниями, в том числе на выставочных проектах. С 2014 года все выставочные проекты, на которых я принимал участие, были по своей сути мультимедийными и вполне хватало pipeline и инструментария классического видео и CG продакшена, что бы решать все производственные потребности.

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

Проект был осложнён ещё важными факторами:

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

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

Решение надо было искать крайне оперативно и сразу вводить в производственный процесс. Использовать решения типа БД на основе ERP "SAP" или иных аналогичных систем, каких-то готовых CRM решений было не реально, так как само их развёртывание, настройка в внедрения требует и времени (от полугода в случае с SAP), привлечения команды IT специалистов, и главного - чёткого ТЗ на старте.

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

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

От Access отказались сразу - взаимодействие с одной БД сразу множества специалистов онлайн показалась нам сомнительной перспективой в этом Microsoft инструменте, даже при развёртывании Sharepoint (возможно, что скиллы мои и моего коллеги, в этом анализе, Владимира Гусева были просто недостаточны).

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

Потом сделали поиск в области онлайн БД. В поле зрения попали такие сервисы, как Zoho creator, Bubble, FileMaker, GetReport, QuintaDB (тогда ещё mytaskhelper). Все эти сервисы по своему прекрасны, но моих скиллов для самостоятельного изучения и понимания хватило на два решения - GetReport и QuintaDB. Именно они показались самым оптимальным решением на тот момент.

Как я писал уже выше, проект завершился преждевременно и экстренно, так что копать тему глубже тогда не вышло. Остался вывод - сервисы GetReport и QuintaDB нам должны по идеи подойти.

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

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

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

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

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

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

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

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

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

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

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

Вот на примере экспоната условный и достаточно упрощённый производственный цикл (канбан):

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

В общем - все эти ситуации QuintaDB помола нам автоматизировать и разрулить, за счёт ряда функционала:

• Автоматизированные рассылки email всем курирующим специалистам информации об изменениях (включая смс уведомления). Достаточно было изменить букву в любой ячейки, что бы все ответственные получали автоматический email что, кем, когда и где было изменено.
• Каскад специализированных отчётов со сложным производственным сценарием, который автоматически меняли свой состав записей, в зависимости от конкретных показателей в конкретных статусных ячейках конкретной записи.
• Возможности разделения прав для отображения различных отчётов различным производственным группам и специалистам.
• Возможность публикации отчётов по внешним авторизированным ссылкам для внешних специалистов, без заведения их в рабочие группы внутри сервиса QuintaDB.
• Возможность организации портала для внешних пользователей с персональными ЛК, для накопления там необходимой информации по отдельным таблицам, отчётам из БД и статистики.

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

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

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

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

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

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

Но прежде, чем доработать шаблон БД выставочного проекта и каркаса автоматизации, мы снова провели исследования.

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

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

Значит решение надо было искать среди отечественного разработчика.

Поиск показал, что музеи, в основном, используют следующие информационные системы - "КАМИС", СУБД "Ника" и АС "Музей" ГИВЦ:

• АС "Музей" ГИВЦ - больше похожа на надстройку к 1C и по юзабилити и внедрению у меня лично вызвал сомнения (хотя сама по себе интеграция с 1С это круто, конечно).
• СУБД "Ника" - похоже, что или уже не поддерживается, или проект совсем закрыт.
  
• КАМИС - именно этот сервис произвел самое обнадёживающее впечатление и желание её освоить и внедрить.
• Даже пообщались с представителями SAP в Росcии - но такой подход явно тяжеловесен и требует серьёзной мотивации, финансовых и временных затрат, хотя, пожалуй, является самым промышленным решением.

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

Но не в нашем случае. Это именно БД, без возможности привязки производственных процессов.

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

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

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

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

• Настойка интеграции БД QuintaDB c 1C через сервисы Zapier или Integromat (или и вовсе по API).
• Использование RPA робота, типа сервиса Sherpa.

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

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

А какие Вы используете онлайн БД на своих проектах, в чём их фишка? Напишите в комментариях, буду очень признателен.