Totum — open source конструктор CRM/ERP и произвольных учетных систем (PHP + PgSQL)
В двух словах — продвинутые таблицы. Ориентирован на отдельных разработчиков или микрокоманды из двух-трех человек. Подходит начинающим разработчикам и бизнес-аналитикам, желающим превратить свое понимание бизнеса в готовое решение или быстро разработать проект под конкретного клиента. Для небольших бизнес-ниш — в которых нет типовых решений. Small-code принцип — множество простых, ситуационных кодов. Есть подробная документация и видео. Устанавливается на собственный сервер за 5 мин. Со временем позволит выгружать разработанные на нем решения с коммерческими лицензиями с использованием встроенной защиты.
Для каких задач
Разработка custom CRM/ERP или любого другого учета для небольших компаний
Лично мы сделали и эксплуатируем несколько проектов с ценой разработки 300—1500К.
Быстрая разработка коробочных CRM/ERP для небольших ниш
В малом бизнесе есть множество небольших областей, в которых требуются специализированные CRM/ERP/Учетные системы. Так как сегменты рынка небольшие, в продуктах крупных разработчиков есть пробелы, не покрывающие мелкие специфические задачи. Идея Totum в том, чтобы упростить разработку нишевых CRM/ERP, сделав ее возможной для отдельных разработчиков и рентабельной для небольших команд из 2-3 человек.
Таблицы + код + браузер
Основа Totum — таблицы. Это чем-то похоже на недавно вышедший у Amazon Honeycode. Но в Totum таблицы выступают как общая концепция организации информации. Данные можно разместить не только в таблице со строками, но и над ней или после нее. Можно быстро накидать нужные поля мышкой или заморочиться и настроить их внешний вид, адаптивность, объединить в группы, сделать подсветку и тд.
Таблиц может быть много. Предусмотрены разные типы таблиц под разные задачи: хранение данных, циклические заказы или проекты, временные отчеты или всплывающие окна.
Для полей внутри мы сделали 15 типов:
Поля добавляются мышкой. Настройки полей выбираются мышкой и их не так много. Для числового поля это будут:
Часть полей в решении отвечает за ввод данных пользователем, часть за вычисление значений и выполнение действий или все вместе. Для того, чтобы это обеспечить, коды пишутся в специальных окнах в настройках поля. Totum обеспечивает подсветку, поиск и подстановку адресов таблиц и других полей, переменных и функций, а также автозаполняет параметры функций. Сделано это на основе codemirror. Про коды и их разделение я расскажу чуть дальше. Коды простые и с ними могут работать начинающие разработчики или бизнес-аналитики.
Интерфейс у Создателя-разработчика тот же, что и у пользователя, но с дополнительными элементами управления, которые создатель может быстро скрыть/показать. Можно на время переключиться в вид конкретного пользователя, чтобы оценить, как у него выглядит система. В одной и той же таблице различные роли могут видеть/изменять разные наборы полей и строк. Можно создать не только пользователя-человека, но и пользователя-API и настроить ему собственный доступ.
Разработчику не нужно быть full-stack программистом, чтобы собрать конечное решение на Totum. Знание html, адресация доменов и общие познания про то, как работает интернет, будут в плюс, но вообще нужно знать лишь сам Totum.
Small-code принцип
Totum основан на небольших кодах, разделенных по типам действия — одни коды вычисляют значение в поле аналогично формуле Excel, другие следят за триггерами изменений и — если они сработали — выполняют написанные в них действия. Третий тип кодов отвечает за внешний вид полей в зависимости от набора данных в схеме. Если эти коды выполняются для таблицы с несколькими строками, то их выполнение будет повторено для каждой изменяемой строки. Обычно коды маленькие. В реальных проектах у нас всего пару раз были коды более 100 строк — обычно 5-10. С таким кодом легко может разобраться начинающий разработчик. Преимущество же кода перед BPMS в том, что на нем проще и понятнее написать разветвленную логику (во избежание холивара по BPMS — это наше субъективное мнение).
Код, вычисляющий значение поля, не может выполнить действие или изменить форматирование — он замкнут сам в себе. Если в нем использованы какие-либо переменные, то они существуют только в момент выполнения этого кода в конкретном поле и никак не пересекаются с другими полями. Имеют декларативную логику:
Это не синтаксис, про синтаксис чуть дальше 🙂
Код действия выполняется только при срабатывании триггеров: изменение значения в поле, добавление или удаление стоки. Для кнопок триггер один — нажатие кнопки. Они тоже замкнуты в себе и никак не пересекаются с другими кодами. Можно использовать одинаковые переменные для кода значений и кода действий в одном поле. Коды действий работают в похожей логике:
Код форматирования может повлиять только на внешний вид своего поля. С ним все просто — он выполняется, если пользователь смотрит на таблицу, при любом изменении в этой таблице:
Чтобы это работало, должен быть известен порядок выполнения — он есть. У каждого поля в таблице есть порядковый номер sort. Сначала считаются значения полей в порядке sort, потом действия в таком же порядке и затем форматирование. В интерфейсе поля показываются в этом же порядке. Да, есть возможность показать поле не в том месте, в котором оно рассчитывается, но об этом сейчас не будем.
Таблицы же могут быть на миллионы строк — они же не будут целиком пересчитываться при изменении? Не будут. В Totum есть понятие «единица пересчета». Она может быть «таблица целиком» или «строка целиком». Разные типы таблиц имеют разные единицы пересчета. Те типы, у которых единица пересчета «строка целиком», при изменении пересчитывают только те строки, в которых произошли изменения. Действия выполняются только при срабатывании триггера. Форматирование считается только на те поля, которые видны пользователю.
Если в результате расчета или действия в таблице что-то изменилось — то при записи изменений у нее изменяется «транзакционный номер». При начале пересчета этот номер запоминается и сравнивается с номером этой же таблицы по окончании пересчета и перед записью. Если номера не совпали, то это значит, что за время операции таблица была изменена другим пользователем. Тогда расчет можно отменить, продолжить или запустить его еще раз взяв новые исходные данные. Это настраивается для каждой таблицы и позволяет разработчику в два клика управлять требуемым уровнем согласованности данных и обеспечивает многопользовательский режим. Для таблиц, в которые осуществляется непересекающаяся запись, — эту проверку можно отключить. Еще одним преимуществом этой модели является то, что вся цепочка действий и пересчетов, задействующая несколько таблиц будет отменена при наличии ошибки или по срабатыванию специально заложенной отмены без записи каких-либо изменений в базу. Открытая у нескольких пользователей таблица сама не обновляется, но они видят предупреждение, что другой пользователь внес в нее изменение которое текущий пользователь еще не видит. Его тоже можно отключить.
Totum-code
Totum написан на PHP, но внутри программируется собственным языком — Totum-кодом. Он призван упростить задачу разработки для новичков. Упрощали по-максимуму и затачивали под таблицы и поля, которые разработчик видит внутри Totum. Вызов и запись данных тоже осуществляется в Totum-коде, SQL знать не нужно.
Базис выглядит так:
Есть еще немного мелочей, но они уже второстепенные. Все остальное выполняется функциями. Например:
Какие языки программирования подойдут для написания CRM?
Всем доброго времени суток.
Являюсь веб-разработчиком и часто встречаюсь со всякими амо црм и т.п.
Как по мне-то можно реализовать интересней и удобней, как для пользователя.
Был небольшой опыт в написании на php админки для регистрации клиентов и вывод данных клиенту по номеру договора.
Хочу аналогичным способом написать CRM на php, js, ajax на обычном sql, который предлагает любой хостинг.
Идея реализовать таким образом, чтобы клиент мог сам редактировать и создавать любой стиль форм, звонки на разные операторы, запись разговоров, регистрация клиентом своих грубо говоря исполнителей, которые будут звонить и обрабатывать заказы с записью разговоров, заметками, временем ответов на заявку (полный контроль над сотрудниками компании, которая имеет главный оплаченный аккаунт).
Весь функционал, принцип действия, удобства и т.п. пишется, пока сложно сказать..
Так вот, вопрос. Допустим 100 человек будет в системе обрабатывать хотя бы 5-10 заказов в день.
Это +500-1000 новых записей в базе данных. Какие у меня могут быть проблемы на этом этапе, помимо тормозов самой базы или стоит как-то базы разделять и сделать больше 1й?
Может стоит посмотреть в сторону какого-то фрейморка или языка программирования для реализации данного проекта более правильно, быстрее. Чтобы через пол года он не начал тормозить и минутами обрабатывать запросы от большого количества данных.
Спасибо всем, кто откликнется и поделится своим опытом
На чём писать CRM?
Привет друзья!
Я изучаю этот вопрос, интересно мнение сообщества.
Предполагается создание модульной системы, набор модулей выбирается под задачи, телефония, почта. В общем-то стандартный набор. Готовые решения изучаем, но наш случай, когда специфика очень большая, в основе логики.
В общем, нужно на ёлку залезть и не поцарапаться.
Оценить 8 комментариев
Пишите на том, что лучше всего знайте. Это первое и единственное что нужно учитывать.
Уровень вхождения. Специалисты не должны быть на «вес золота».
Открываем hh.ru по Вашему региону и ищем резюме с ключевыми словами C#, Java, PHP и т.д. Исходя из количества потенциальных кандидатов и их запросов понимаем будут ли они на «вес золота» или нет.
Не понимаю в чем проблема сделать приложение в браузере, т.е. чтобы Ваша CRM открывалась через любой бразуер. По этому принципу работает Мегаплан, Амо и т.д. Да почти любая соверменная CRM. Возьмите на основу этот же путь, как вариант.
UPDATE 16.12.2016
Анатолий ниже в комментах к моему ответу Вы пишите, что большенство людей советуют Вам использовать именно облачную реализацию. Позвольте поделиться своими мыслями по этому вопросу.
Разрабатывая любое десктопное приложение рано или поздно Вы столкнетесь с проблемой его корректной работы на разных машинах. К примеру, создали Вы програмку под Windows. На одной машине с Win 7 она работает прекрасно, а на Win 7 SP 1 уже выдает какую-то ошибку. Еще пример, на 5 машинах стоит одинаковая ОС. На 4-х из них Ваша программа работает прекрасно, а на 5-й какое-то там окно не отображается. Почему так? Надо садиться и разбираться, копаясь конкретно в настройках этой машины, выесняя что там не так, чего там не стои или стоит лишнего.
Всем этим я хочу привести Вас к одной единственной идеи: есть очень большая разница, между приложением, которое должно работать на одной машине и, приложением, которое должно выполняться на десятках/сотнях/тысячах рабочих станций.
На чём лучше писать CRM-систему?
Время пришло, понадобилась CRM-система. Готовые ненужны.
Для бэкенда два варианта:
1. Python/Django. Здесь я спокоен. Куча проверенных временем батареек. Всё работает в промышленных масштабах.
И так, что же выбрать? Вот только не надо шуточек за 300, что нода только для чатиков.
P.S.: Может у кого-то был опыт, делать что-то подобное на node.js. Стоит оно того или нет? Или не заниматься фигнёй, бросать все эти модные штуки и брать проверенный временем инструмент.
UPD: Создатель Node.js: «Это далеко не лучшая система(node.js) для серверного софта.». В общем, если уж создатель на неё плюнул, то и мне нестоит это трогать. А свой выбор я уже сделал и это Rust. Да, я люблю приключения 😉 Python/Django.
Не все CRM ровняются под Bitrix24, чтобы тормозить 🙂
пользуюсь sap crm, тормозит 😉
потому-что crm не делает ничего про «перфоманс», вообще.
Ну я слушал презентацию SignalR Core, вроде как обещает быть конфеткой, но когда? Насчет M2M, его как раз не осиливает 90% ормок, которых я знаю, м2м было сильной стороной именно энтитифреймворка. Майкрасофт слишком медленно чухается, в той же скале, есть плей фреймворк, в котором есть вебсокеты и даже socket.io, где это все работает на акке, ормок для скалы дохренище. Энтитифрейморк 7 еще не вылечился от элементарных детских болезней, например, если положить модель в отдельную сборку, то с ней не работают миграции, хорошо, что я нигде миграции не использовал никогда.
И то и то уже отлично работают.
Правда IDE пока нормального нет. Ну как, есть райдер, который еще пилить и есть vscode и monodevelop дабы поржать.
Выбор очевиден
1. Python/Django. Здесь я спокоен. Куча проверенных временем батареек. Всё работает в промышленных масштабах.
2. JS/Node.js. Тут всё меняется так быстро, что уже опять новый форк node.js пилят. А я всё хочу полностью на js перейти.
Отличный выбор. Событийная асинхронность. Есть такие замечательные вещи как тот же socket.io и meteor.js. С их помощью пилить real-time просто сказка.
P.S.: Может у кого-то был опыт, делать что-то подобное на node.js. Стоит оно того или нет? Или не заниматься фигнёй, бросать все эти модные штуки и брать проверенный временем инструмент.
CRM системы: что это? Простыми словами
Где вы храните клиентов? На бумажке, в телефоне, в ежедневнике, в экселе? Или вам в который раз предлагают CRM систему, но у вас нет полного понимания, что это такое и как это работает.
Эта информация не для программистов, айтишников и т.д. Она для владельцев бизнеса, которые хотят понять, что такое CRM система. Не читать про выгоды, пользу, кому она нужна и что это дает, а прежде всего ПОНЯТЬ. Большинство информации на эту тему написано очень умным языком. Даже простые статьи написаны так, как будто люди боятся показаться не профессионалами. И прошу меня простить, если кому-то покажется, что я написал все это слишком простым языком. Я хочу, чтобы вы поняли и разобрались в этом, так как разбираетесь в своем бизнесе, а не считали меня экспертом.
Поэтому давайте разберем CRM систему на части. К чему CRM система относится в бизнесе? Продажи. Что нам нужно для продаж? Клиенты. Поэтому первые две самые важные вещи которые должны у нас быть, и они есть в любой CRM системе, это клиенты и продажи.
Итак. Клиенты. Где вы храните клиентов? На бумажке, в телефоне, в ежедневнике, в экселе?
Вы и сами можете подтвердить что все эти варианты не удобны тем, что:
Решение отличное. Но есть недостаток. Скорость!
Что у нас есть в картотеке? Куча карточек чего-либо. В нашем случае клиентов.
Вот и мы заведем на каждого клиента карточку, как в картотеке. В этой карточке у нас будет храниться вся информация на клиента. Зашли в карточку, и все как на ладони.
Какую информацию будем хранить?
Ту, что нам нужна для того, чтобы успешно продавать и принимать верные решения. Такую информацию по клиенту можно разбить на две части.
Как ее будем хранить?
Согласитесь, что в любой системе должен быть порядок, а иначе это уже не система.
Как мы бы это сделали в картотеке? В самом простом варианте у нас бы были одинаковые для всех клиентов и карточек поля: телефон, почта и т.д. В такие поля мы легко можем поместить информацию по типу 1.
А что делать со всей информацией, которая связана с взаимодействиями с клиентом? У нее есть одна особенность. Она зависит от времени. Вот и расположим ее в зависимости от времени, чтобы вначале видеть самую свежую информацию, а потом более позднюю.
В итоге, мы имеем карточку клиента, где хранится вся основная информация о клиенте. Она расположена в полях. На картинке внизу эти поля слева. Вся информация о взаимодействии с клиентом расположена в зависимости от времени. На картинке внизу это справа.
Осталось решить еще один момент. Клиентов-то у нас не один, а много. Как будем их всех размещать? В картотеке все карточки расположены просто по алфавиту. В нашем же случае ничего лучше списка пока не было придумано.
Делаем простой список клиентов. Сколько клиентов в списке нам без разницы. Потому что нужного или нужных нам клиентов мы найдем с помощью поиска или с помощью фильтра.
А если вы зайдете в любую CRM систему, вы это и увидите. Список клиентов, и у каждого клиента карточка с информаций о нем, а также поиск с фильтром.
Таким образом, у нас и получилась первая из основных частей CRM системы. На самом деле некоторым и этого достаточно. Клиентов уже легко искать и информация не теряется.
Но кому-то этого не хватает. Поэтому пойдем дальше. Мы же хотим видеть, что мы клиенту продавали!
Что будем делать с информацией о продажах?
Мы можем указывать всю информацию о продажах прямо в карточке клиента. Однако возникает несколько неудобств:
Если мы рассмотрим информацию о любой продаже, то как и в случае с клиентом мы сможем ее разбить на две части:
Тогда есть простое решение. Если клиент и продажа так схожи, то давайте для продажи сделаем такую же карточку как и для клиента. Сделаем список всех продаж, как и клиентов, в котором будет легко найти нужную.
Но у продажи и клиента все же есть важное различие. Продажа, в отличии от клиента, это процесс. И как у любого процесса, у нее есть этапы. Т.е. продажа может начинаться – мы вступили в контакт с клиентом, и может завершаться – мы совершили продажу, либо нет. Между началом и концом есть еще и свои этапы.
Например, сначала продавец общается с клиентом по телефону, потом встречается, потом делает ему коммерческое предложение, потом выставляет счет и получает оплату. У каждого бизнеса своя специфика и свои этапы. Но они есть всегда. Просто потому, что у любого процесса они есть. Даже если вы просто захотите выйти из дома, вам сначала нужно одеться, открыть дверь, потом выйти. Уже как минимум три этапа.
Причем не обязательно, что при переходе от первого этапа до последнего придется проходить обязательно по каждому этапу. Вы можете и без одежды выйти на улицу. В продажах, если вам позвонил клиент и сказал: “я хочу купить”, и он знает конкретно, что хочет купить, вы же не будете настаивать на том, чтобы скинуть ему коммерческое предложение. Вы ему выставляете счет. И фактически вы продаете ему без этапа коммерческое предложение. Вы его перепрыгиваете. В этом нет ничего плохого.
Что будем делать с информацией по этапам?
Остается только одно: связать продажи и клиентов.
Есть у нас список клиентов и список продаж с карточками. Но пока они у нас не связанны.
По сути в этом ничего сложного. Например, когда вы заходите в контакт или фейсбук, вы можете зайти в список всех друзей и из всех пользователей социальной сети увидеть только своих друзей. Т.е. по сути увидеть только тех, кто связаны “дружбой” с вами. Так и здесь.
Сделаем так, что в карточке клиента будет раздел, куда мы можем зайти и увидеть список всех продаж этого клиента и оттуда сможем открыть карточки этих продаж. То же самое сделаем в карточке продажи, чтобы легко было попасть в карточку клиента. Получается, что теперь у нас клиенты и продажи связанны.
Именно это вы и увидите при входе в любую CRM систему:
Для этого введем новое понятие. Сущность – это различимый объект; объект, который мы можем отличить от другого. В нашей системе мы будем под сущностью понимать некий объект, который каким-либо образом отображается (например в виде карточки), имеет свои поля ввода (например у клиента – телефон, почта, город; у сделки – сумма) и имеет связи (в нашем случае, например, у клиента есть связи с продажами).
Т.е. клиент и продажа это отдельные сущности. И они связанны друг с другом связями как на картинке. Одному клиенту может быть совершено несколько продаж;
Для того, чтобы полноценно работать с клиентами, не хватает только одного.
Мы не редко забываем, что нужно кому-то позвонить, написать и т.д. Кто-то для этого использует ежедневник, кто-то будильник, а кто-то полагается на память.
Давайте добавим просто возможность ставить себе задачи. К счастью, с задачами всем все понятно. Вопрос только в том как они будут отображаться в системе.
Воспользуемся понятием сущности, которое мы ввели. Мы договорились, что под сущностью понимаем некий объект, который каким-либо образом отображается (в случае задачи, это может быть карточка, только не такая как у продажи и клиента), а имеет свои поля ввода (у задачи это срок выполнения, приоритет и т.д.) и имеет связи (задача связанна либо, с продажей либо с контактом).
Т.е. задача — это сущность со своими связями.
Куда поместим задачи в системе?
Во-первых, удобней всего, чтобы они были распложены списком как контакты и продажи.
Сделаем отдельный список, где отображаются все наши задачи, чтобы все их видеть и будем по порядку выполнять. А все они у нас связанны с клиентом либо с продажей. Поэтому мы через них легко попадаем в клиента или продажу.
И второй вопрос на который нам надо ответить: Где отображать задачи в карточке клиента?
Располагать их также как продажи не совсем удобно.
У задач есть одна особенность. Сами задачи тесно связаны с процессом общения с клиентом. Мы звоним, общаемся, после этого пишем комментарий, ставим задачу, посылаем письмо. Потом по задаче снова звоним или идем на встречу. Т.е. для них очень важно, когда задачи поставили и когда их надо выполнить.
Поэтому пусть задачи будут отображаться там же где комментарии и звонки. Там, где расположена вся информация о взаимодействии с клиентом в зависимости от времени.
Если вы зайдете практически в любую CRM систему, то это и увидите. Список задач и возможность ставить задачи в карточке продажи и карточке клиента. В итоге получаем карточку продажи, карточку клиента и задачи.
Мы получили базу клиентов, в которой хранится вся информация о них. И получили понимание кому что продается. И более того, за счет этапов продажи и задач мы эти продажи даже контролируем, т.е. управляем ими.
CRM – управление взаимоотношениями с клиентами. Управляем? Управляем.
По сути, это и есть основной функционал CRM системы. Но согласитесь, что ездить на “мерседес” гораздо комфортней, чем на “жигули”. Так давайте и нашу систему немного прокачаем. Добавим возможностей.
Клиентов и продаж нам может не хватать. Возьмем сразу пример посложней, чтобы понять насколько все просто.
Кроме клиентов у нас могут быть: поставщики, у которых мы берем товар, чтобы перепродать; логистические компании, с которыми мы можем работать для доставки груза; список самого товара, который мы продаем; документы связанные со всем этим – например, договора.
Вроде бы много всего. Но вспомним, что у нас есть – сущности и связи. Чтобы легко разобраться определим, что все это – поставщики, логистические компании, документы и товары — это новые сущности.
Согласитесь, что у каждого из них должен быть список и карточка. Список, чтобы легко найти нужного поставщика, товар и т.д. Карточка, чтобы там была вся информация о них. Этот вопрос закрыли. Тут ничего сложного.
Все, что нам осталось, это использовать наш второй инструмент – связи. И связать эти сущности друг с другом и с тем, что у нас уже есть – клиент, продажа, задача.
Связи зависят от бизнес-процессов. Рассмотрим вариант, когда мы покупаем товар у поставщика и перепродаем его клиенту.
С чем связан клиент?
По аналогии с продажами мы можем легко видеть в карточке клиента документы, которые с ним связаны.
С чем связана продажа?
С чем связан поставщик?
Правда в данном случае понятие “продажи” зашло за пределы просто получения денег. Тут продажа у нас заканчивается когда клиент получил продукт, который мы предоставляем. Но где она заканчивается мы решаем сами.
И вот насколько бы сложным все это не казалось в начале, из кирпичиков сущностей и связей мы и строим нашу систему. А как все это просто автоматизировать, так чтобы многие процессы происходили автоматически, я распишу в другой раз.
Хотя мы уже вышли за рамки CRM системы. Но это не проблема. Я хотел, чтобы вы поняли, что в любой системе нет ничего сложного.
А если вернуться к понятию CRM системы. Список контактов, список продаж со статусами и задачи — это и есть самый простой пример CRM системы. Что это может вам дать? Любой владелец бизнеса поймет это лучше чем продавец, который хочет ему продать. А все остальное — это моменты удобства, которые позволяют более эффективно осуществлять продажи.
В итоге все равно, система должна быть такой, какая нужна вам, а не такой, какой ее замыслили другие. Она должна автоматизировать ваши бизнес-процессы, а не становиться еще одной обузой.
