Добрый день.Мы опубликовали систему управления предприятием Papyrus в исходных кодах под именем OpenPapyrus. Проект так же опубликован на сервере sourceforge.
Технические аспекты я распишу в отдельной статье, а здесь кратко расскажу о том, что такое OpenPapyrus и почему эта система стоит того, чтобы с ней ознакомиться и начать ее использовать.
OpenPapyrus — инфраструктурная система для управления бизнесом, над которой мы работаем более 20 лет (с 1996 года), развив в ней обширный функционал для управления бизнесом в широком наборе сегментов.
До текущего момента мы продавали систему Papyrus только как проприетарный продукт. В дальнейшем мы будем развивать одновременно оба продукта — проприетарный и открытый (тем более, что это — почти одно и то же).
Мы считаем (Open)Papyrus одной из лучших систем такого класса на российском рынке. Утверждение, конечно, сильное и субъективное, но теперь, когда
Вот, возможно не полный, список сегментов бизнеса, в которых OpenPapyrus превосходно работает:
- Розничная торговля
- Аптеки
- Оптовая торговля
- Кафе и рестораны
- Салоны красоты
- Фитнес клубы и спортивные центры
- Небольшое производство
OpenPapyrus умеет очень-очень-очень много всего и почти все, из этого много, делает хорошо. Попытка перечислить функциональные возможности системы лежит там же на github. Мы постарались классифицировать весь функционал и составить перечень, по которому можно было бы сравнивать систему с конкурирующими решениями. Но на мой взгляд, попытка оказалась не очень успешной (хотя этот документ мы, по-возможности, поддерживаем в актуальном состоянии).
Очень тезисная колонка функциональных блоков такова:
- Бухгалтерский учет
- Управление закупками
- Управление продажами
- Управление расчетами с контрагентами
- Управление розничными продажами
- Point-of-sale
- Управление производством
- Управление персональными событиями
- Управление проектами и задачами
- Инфраструктурный функционал
Будет, вероятно, уместным обратить внимание, что у нас есть решение для мобильных торговых агентов (StyloAgent), мобильный официант для ресторанов (StyloWaiter) и модуль для терминалов сбора данных (BHT). Эти продукты мы пока в открытый доступ не выкладываем, но не потому, что жалко, а из-за технических препятствий.
Система разрабатывается и развивается в соответствии с несколькими не сложными принципами, которые, в основном, и определяют ее облик:
- Концептуальная целостность и непротиворечивость. Если по-человечески, то это значит, например, что мы не делаем заплаток для того, чтобы удовлетворить какой-либо запрос клиента, но применяем и(или) расширяем существующие понятия для этого. Если же разработка новой концепции все же необходима, то планируем и прорабатываем ее с расчетом на будущее использование.
- Максимальная унификация. Жаль, что термин «принцип Оккама» измотали применением к месту и не к месту, а то бы он здесь подошел. Но в общем, идея та же: если некая сущность может быть отражена в системе один раз и затем повторно использоваться, то незачем ее и множить.
Простой пример: персоналии, как субъекты гражданского права, представлены одноименным объектом данных, а не набором «покупатели», «поставщики», «физики», «юрики» и т.д. Вопрос классификации при использовании — техническая проблема.
Аналогично, понятия «склад», «адрес», «складская ячейка» и «подразделение организации» все представляются через единый функциональный объект «локация».
Похожие подходы используются и в разработке кода системы — большинство блоков строятся по шаблонным методам с предельно унифицированными интерфейсами. Результат легко заметен по размеру дистрибутива — он очень скромный.
- Примат снижения себестоимости поддержки. Выражаясь русским языком: если два и более клиента обратились по одному поводу, то дешевле что-то поменять в системе, чем отвечать на такие же обращения в будущем.
- Устранение дефектов имеет максимальный приоритет перед всеми остальными проблемами и выполняется без каких либо условий. С этим все более или менее понятно. Очевидно, этот принцип туго связан с предыдущим.
Учитывая возраст системы и то, что некоторые компании используют ее по 10-20 лет, можно предположить, что эти принципы работают. У них есть и побочный эффект: система в конце концов оказалась весьма не очевидной в настройке, что, однако, перекрывается простотой использования для конечных пользователей.
Функциональных отличий между Papyrus и OpenPapyrus нет. Мы, правда, пока не до конца понимаем как будут уживаться оба этих варианта с маркетинговой точки зрения.
Поддержка остается платной, но мы очень рассчитываем на то, что будет достаточно людей и компаний, которые сами смогут разобраться что и как, и, того паче, смогут продавать свои консультационные услуги другим компаниям.
Инструкции по установке есть и на github'е и на sourceforge. Инсталляция для ознакомления очень простая. Инструкций по сборке из исходных кодов пока нет, но клон исходных кодов точно собирается — мы это тщательно проверили.
Документация (большая, но все равно, не полная) есть там же.
Перед тем, как закруглиться, приведу пару любопытных фактов:
- Papyrus умеет управлять web-контентом. Мы эту feature не позиционируем как тиражируемую, но содержанием сайта компании Петроглиф и сайтом Universe-HTT (там, например, есть один из лучших справочников штрихкодов в сети) управляет сервер Papyrus, накрытый обвязками из Java из т.д.
- Протокол версий Papyrus ведется с самого его рождения. В удобоваримом виде он доступен на сайте компании Петроглиф. Конвертация в html осуществляется автоматически тем же самым Papyrus'ом. В релизах на github мы даем соответствующую ссылку.
Ну и напоследок. Ради чего? Основная причина — экзистенциальная: стоит поделиться тем, что делали 20 с лишним лет, с остальным миром, тем более, что мы сами пользуемся результатами работы open source-сообщества. Остальные причины мелкие и скучные — вы и сами о них знаете.