Нужны ли людям онлайн-конструкторы бизнес-приложений

    Мы создаём онлайн-конструктор учетно-отчетных систем, который позволяет без программирования создать веб-приложение. Помимо нашего продукта на рынке есть еще десятки конструкторов как от небольших и средних компаний (Zoho Creator, QuickBase, Caspio, Zengine), так и от гигантов (Oracle Application Express, Microsoft PowerApps).

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

    О конструкторах баз данных и бизнес приложений

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

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

    В основном из-за простоты, гибкости и отсутствия необходимости в программировании (но при этом доступности VBA), в 90-е и 2000-е с помощью Excel и Access создавались миллионы учётно-отчётных приложений. Учётная система может начинаться с небольшого приложения из 3 таблиц и пары форм. В случае востребованности приложения бизнесом, оно начинает обрастать новым функционалом. И если вдруг оказывается, что выбранная платформа не позволяет реализовать нужную опцию, приходится всё переделывать на другой платформе/языке/CMS.

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

    Проблема 1: баланс простоты и функциональности

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

    Проблема 2: сложный переход с уже используемого решения на конструктор

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

    Как может выглядеть идеальное решение

    Кажется, что идеальный с точки зрения функциональности конструктор бизнес-приложений должен иметь:

    • Максимальную функциональность учётных форм и таблиц. При этом все типичные интерфейсы и учетные формы должны генерироваться автоматически – без программирования.
    • Сверх гибкую систему прав. Права на редактирование и просмотр должны даваться на столбцы и строки вплоть до ячейки в таблице.
    • Конструктор процессов заполнения данных. Для каждой записи в базе должна быть возможность назначить свой процесс её заполнения.
    • Возможность в любое место системы добавить произвольное поведение и оформление. Нужно иметь возможность к любому элементу системы добавить серверный и клиентский JavaScript, можно писать библиотеки на C#/Java, есть REST API.
    • Возможность загрузить в веб-приложение старые табличные данные с сохранением их структуры.

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

    Как вариант — с помощью многоступенчатых интерфейсов при создании и настройке приложения:

    — Первая ступень: пользователю видны 2-3 основных параметра;
    — Вторая ступень: пользователю открывается все дополнительные настройки;
    — Третья ступень: открывается возможность написать свой код, если нет нужного функционала.

    Пример ступенчатой работы с полями таблицы:

    • Первая ступень: пользователь задаёт название поля, тип поля и признак уникальности значений.
    • Вторая ступень: пользователю открывается настройки отображения поля в таблице и форме редактирования, возможность задать обязательность поля в зависимости от состояния записи, группировка полей, настройки переходов в другие таблице при клике по значению в поле.
    • Третья ступень: возможность самостоятельно на JavaScript описать алгоритм отображения и поведения поля.

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

    Буду рад в комментариях обсудить перспективы конструкторов бизнес-приложений.
    Кстати, посмотреть наш сервис можно здесь: getreport.pro
    Share post

    Comments 44

      0
      Здравствуйте Сергей.

      Довольно, интересную тему вы затронули, и считаю, что данная ниша, действительна пуста (* делаем вид, что нет Oracle APEX/PLSQL, в какой-то степени Google Sheets/java-script, 1C/VB6-факту тотже VBA) — но эти решение или на порядок сложней, или не обладаю нужными возможностями.

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

      Что требовалось(остальная переписка ниже по ссылке):

      Может кто знает замену Excel, но с WEB — интерфейсом.

      Для, чего, использую Excel:
      Очень часто, требуется анализировать много данных из различных источников:
      * Данные получаемые из разных БД (postgresql, oracle, sql server, db2 ......)
      * Данные из различных тестовых форматов (xml, cvs, dat, SuperMegaCorporateFormat)
      * Книги Excel
      * WEB — ресурсы (без заумных двухфакторных аутентификаций)
      В большинстве случаев применяю Excel, когда анализ, требует «пользовательских действий».
      К примеру, пользователю выводятся данные на одной экранной форме, из разных баз(полученные sql — запросами), а также данные из Excel файлов(чем не база?), которые он просматривает, делает определенные действия(при помощи реализованного интерфейса), далее формируется отчет(xml/xlsx/прямую запись в базу)+иногда отправка на Email и прочие плюшки.
      Условия, по определенным причинам, пользователя из этого процесса удалить нельзя.
      Сейчас, все это реализуется на Windows-->Office/Excel/VBA(Интерфейс-логика-получение-данных)/

      Требуется найти «кроссплатформенную WEB» замену этому поистине многофункциональному инструменту.
      Главные критерии к инструменту: не сильно меньшая скорость реализации чем в Excel, готов на обучение (могу выделить месяца 3).
      Price: хотелось бы не дороже 1000$

      Пока сам вижу единственную замену в качестве Oracle APEX, vba — заменяю на plsql и по идеи все.

      Также в голове крутятся BPM Pega(vba- заменяем на Java, но с Java это блин надолго ......), и BPMN — Bizagi(vba — заменяем на .Net) — но ценник там ого-го.
      И к сожалению, нет той гибкости, и простоты, какую предлагает Excel, + ко всему этому эти системы не на это «заточены», и их использование выглядит, как использование экскаватора — для вскопки грядки.

      Хотелось бы узнать, подходит ли ваш продукт, под данный кейс(case).

      web-замена-Excel

        0
        Да, подходит.
        Пришлите мне конкретный пример — мы покажем как его сделать у нас.
        +7
        Заголовок статьи и содержание не соответствуют друг другу.
          +1
          Это уже даже не смешно, вы интересно делаете отбор стран — по их коду :)
          Зачем вы убрали из маски номера телефона «7», если, например, из стран с двумя цифрами кода — зарегится уже нельзя? Это отбор такой? только Россия, Америка и ежи с ними?
          Хорошо, что можно вписать просто много единиц :)

          Ну ок, письмо пришло, перехожу по ссылке — в заднем фоне картинка весом почти в мегабайт, страница задумаль на 10 секунд, на телефоне на 25.
          И это на странице с 2 полями и одной кнопкой.
          Т.е. если бы я не ставил цель исследовать систему, то я бы уже «отвалился» :)

          Дальше пошло веселее, но вот я как-то не сразу все понял и не до конца.
          Конструктор запросов страшный, т.е. я зная языки запросов — только смутно понят что где и куда :)
          В целом — наверное имеет право на жизнь, но я могу вам посоветовать реализовать две вещи:
          1. Загрузку по OData
          2. реализацию OData на вашем сервисе.

          Зачем загрузку? Тогда можно, например, без глубоких знаний — тянуть данные и 1С, т.е. по сути прописать к ней путь и доступ.
          А поддержка протокола на вашем сервере — позволит создавать динамические Excel таблицы, т.е. я настроил отчет, выгрузил его в excel, а потом тупо могу в нем нажать обновить, этакой офлайн доступ к данным, видь данные иногда нужны и в офлайне, но и хочется их иногда «дообновлять».
          Это так, мое мнение.

          Но вот первые шаги — переделайте :)
          Ну и замените вот эту чушь на главной странице:
          1C и SAP:
          — Конструирование отчётных форм намного дешевле и быстрее, чем заказ модулей у разработчиков.
          Это вам кто такое сказал? Если у человека есть уровень позволяющий строить запросы у вас, то он точно сможет построить запросы в 1С, и намного намного быстрее и качественее.
          — Отчётные формы могут меняться «на лету», не нужно отдельно обращаться за каждой доработкой.
          Вот это точно уберите, ибо отчеты в 1С все редактируемые, и настраиваемые, если конечно они не написаны через Ж, или по логике запрещена настройка отчета.
          — Доступен в веб-интерфейсе, нет необходимости закупать лицензии на каждое рабочее место.
          1С уже 6 лет как доступна в вебе, тем более есть 1С fresh, которой тоже не надо покупать лицензии а только арендовать, и цены при этом не много выше вашей, причем функций — на порядок больше. Так что лучше перепродумайте свои тезисы.
          А вот к сапу — все эти тезисы подходят.
            0
            А вообще, имеет смысл сравнивать продукт, где стоимость использования 300 руб/сотрудник-месяц с SAP, где цена измеряется десятками миллионами?
              0
              Melex, спасибо за полезные комментарии, в ближайшее время учтём и доработаем сервис.
                0
                Спасибо за полезные комментарии, в ближайшее время учтём и доработаем сервис.
                0
                Похоже на еще один облачный бэкенд типа BaaS
                • UFO just landed and posted this here
                    0
                    1Сники тоже хотели, что бы бухгалтера сами себе программы для отчётности писали. А теперь посмотрим рынок 1С Программистов. Так и с данными системами возникнет новая категория программистов бизнес-приложений. А уж хорошо это или плохо я не берусь судить.
                      0
                      Timur_n, на мой взгляд, бизнесу важно чтоб система работала хорошо, но стоила как можно меньше.
                      Поэтому, если учетное приложение может сконструировать системный аналитик, без программиста — это хорошо. Так как программисты в среднем, более высокооплачиваемая профессия.

                      О возрастающем спросе на такого рода конструкторы, можно почитать в отчете QuickBase

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

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

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


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

                      0
                      Интересная вариант. Не нашел в описание про тестовый период или версию фрии.
                      Смутило что при регистрации просит и телефон и емайл.
                      Как предложение, сделать шаблоны для решения определенных задач (Склад, CRM, Продажи).
                        0
                        Триал версия работает 2 недели. О сроке окончания лицензии написано на странице Мой GetReport
                        Добавим информацию об окончании лицензии в письмо.

                        Спасибо за предложение, шаблоны сейчас делаем.
                        0
                        «Как может выглядеть идеальное решение»
                        Я бы добавил интеграцию с системами проектирования бизнес-процессов (ARIS нотация eEPC, нотация IDEF1X) или собственная возможность проектирования бизнес-процессов. На диаграмме процесса для каждого шага вы указываете роль, форму/документ, действие (создать, изменить, просмотреть, удалить, утвердить, ...), входящие данные, исходящие данные. Из шага проваливаетесь в редактор форм/документов/таблиц/запросов. После формирования диаграммы бизнес-процесса автоматически формируется матрица полномочий, причём полномочия уже настроены (шаги привязаны ролям).
                        Это серьёзная задача, но Вы сами спросили про «идеальное» решение.
                          0
                          Именно к этому мы идём.
                          Каждая строка GetReport может иметь набор состояний. Возможные состояния строк таблицы задаются справочником. Состояние строки называется — Статусом. Для каждой роли можно определить доступные переходы между статусами, права на правку ячеек и добавление строк в определенном статусе.

                          Таким образом, Статусы позволяют определить бизнес-процесс. На каждом шаге бизнес-процесса определённые роли должны заполнять определенные поля, а затем переводить процесс на следующий шаг, изменяя статус объекта.
                          Следующим шагом развития будет добавление к нашему конструктору BPM нотации,

                          Любопытно, что с другого конца к нам двигаются BPM системы, которые реализуют у себя конструкторы таблиц и форм, Есть интересная статья, где сравниваются BPM система Appian и конструкторы баз данных: Zoho Creator., Salesforce Lightning, Microsoft PowerApps.
                          0
                          Тема очень интересная.
                          Мы занимаемся подобным проектом уже много лет, только в десктопном исполнении. Все не хватает времени вывести в общедоступную коробку. Но активно применяем в качестве ядра для построения заказных учетных систем.

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

                          Кроме решения вопросов валидации данных, распределения полномочий и обеспечения возможности групповой работы, одной из главных угроз от настольных «систем» «дикого» учета, таких как Excel и Access, является разрозненность и «ненормальность» данных. В итоге, на местах вместо табличек Excel появляется множество подобных систем, пусть более технологичных. Т.е. не решается основная проблема бизнеса — управление данными и как следствие получения нужной оперативной и/или управленческой отчетности.
                          С таким подходом можно сказать что бизнес не владеет данными, потому как не бизнес, а автор (в вашем случае пользователь) является носителем неотчужденных знаний.

                          Такая система должна являться инструментом в первую очередь для администраторов, а лучше для архитекторов, упрощая развертывание различных приложений в единой информационной среде, обеспечивая целостность и нормальность, иметь единую НСИ. Иначе пользователи нашлепают вам множество тех же экселевских табличек, пусть и в другом виде =)
                            +1
                            можно писать библиотеки на C#/Java, есть REST API.

                            Джва года жду такой конструктор
                              0
                              У нас можно писать на C# в коробочной версии, в SaaS версии пока только на клиентском и серверном JavaScript
                              0
                              Помимо нашего продукта на рынке есть еще десятки конструкторов как от небольших и средних компаний (Zoho Creator, QuickBase, Caspio, Zengine), так и от гигантов (Oracle Application Express, Microsoft PowerApps).
                              Вам стоит посмотреть Airtable.
                                0

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

                                  0
                                  Shamov, всё что нельзя сделать в интерфейсе, можно дописать,
                                  у нас есть серверный и клиентский JavaScript, можно писать библиотеки на C#/Java, есть REST API.
                                    0

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

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

                                        Цена/качество/скорость чего? Первоначального развёртывания (при наличии в конструкторе всего необходимого) или же последующего сопровождения (при возникновении потребности в функционале, отсутствующем в конструкторе)?

                                          0
                                          Кстати, это (функционал, отсутствующий в конструкторе) один из очень важных вопросов. Когда создатели конструктора начинают считать себя самыми умными и заставляют работать только с помощью инструментов конструктора. Типичный пример 1С — нельзя в самом 1С работать напрямую с базой данных через SQL, нельзя создавать свои структуры данных напрямую в БД и тому подобное.
                                          Таких конструкторов надо по максимуму избегать. Создатель конструктора всё равно не сможет втиснуть в конструктор все возможности СУБД или стандартного языка программирования. И отсутствие возможности использовать «низкоуровневые» средства очень дорого обходится в некоторых случаях. А случаи такие случаются намного чаще, чем многие думают. :)))
                                            0
                                            В конструкторе никогда не будет «всего необходимого», даже больше, не нужно пихать в него всё подряд из разных предметных областей, в одну кучу. Многие вещи, которые могут быть унифицированы, могут не требовать программиста, достаточно продвинутого пользователя/конфигураста. Допустим для построения нового отчета, или правки текущего, не всегда нужен программист, с Excel работники справляются. Становится не нужным звено аналитик/программист/тестеровщик, из работник — аналитик — программист — тестеровщик — работник. Программист остается нужен только там, где что-то новое и сложное, рутина по «клепанию формочек», «отчетов», не сложной «бизнес логики», аналог формул Excel — остается на пользователях.

                                            p.s. у автора по доке, «логика» от BD аля visual bd, мне не нравится такой подход, мне нравится подход от бизнес задачи.
                                            Но тут, не так все просто, тут возникает момент-конфликт логики процесса и логики данных в бд, и как это грамотно совместить, т.к. БД у нас на текущий момент реляционные — структура жесткая(1С, magneto и.т.д.) для обхода этого ограничения используют EAV, вот поэтому в 1C и нет простого доступа к BD, ибо запросы нелогичны, но сейчас BD научились, работать с XML/JSON, тоесть по факту они уже не relation, и тут уже возможно поиграть с совмещением не совмещаемого, но с архитектурной точки зрения не все так просто.
                                            Тут все таки автору нужно определится, что он делает за продукт, VisualDB(аналог Access/foxpro) — это одно, Online Excel — это другое (аналог Excel/Google Sheets), Конструктор бизнес приложений (ака BPM) — это третье и довольно сложная штука. Аудитория соответственно разная.


                                              0

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


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

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

                                                Есть еще небольшая прослойка пользователей, которым нужна гибкость, нестандартность, которые, как раз и ищут, то, что в дальнейшем возможно превратится в «четкий, прибитый гвоздями процесс», который даст развитие компании. Им часто нужно покрутить данные, сделать отчеты, посмотреть/оптимизировать процессы и многое другое, где требуется гибкость и думать. По каждому чиху, общаться с аналитиком/разработчиком, ждать хотелку, которая может быть и не нужна, это слишком дорого и долго.
                                                Так, вот для них, такие инструменты, как раз и требуются, точнее есть Excel+Pivot/Access/Visio, но не все работают на windows, да и устанавливаемые приложения неудобны, к примеру разные версии и.т.д.

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

                                                  0

                                                  Компании, которым постоянно требуется перестраивать свои процессы под изменчивую конъюнктуру, — это те компании, которые сами не знают, чем конкретно они занимаются и зачем существуют. Грубо говоря, это пена на поверхности рыночного океана. Нормальный бизнес с такими компаниями не сделаешь. В любой момент ветер может поменяться, и они бесследно растворятся в воздушном потоке. Один раз продать им конструктор, наверное, можно. Но вовсе не факт, что они купят хотя бы одну новую версию через год-два. Чтобы бесперебойно финансировать разработку конструктора, нужны десятки тысяч таких одноразовых покупателей в год. Соответственно, реальная власть в компании-разработчике будет в руках отдела продаж. Разработчики будут делать в конструкторе не те фичи, которые в нём объективно нужны (с точки зрения аналитиков), а только те, которые помогают активнее продавать конструктор (с точки зрения продавцов). Квалифицированные разработчики в такой атмосфере работать не будут, а неквалифицированные смогут сделать только плохой конструктор.

                                                    0
                                                    Почти у каждой компании есть устоявшиеся процессы, которые и составляют 90-98% операционной деятельности, и новые процессы, по которым нет четких правил.
                                                    Для новых процессов и нужны конструкторы, которые позволяют с минимальными затратами разработать софт (пусть с не очень удобным UI или немного кривой схемой БД). Главное, чтобы этот софт можно было легко переделывать. Ведь при начале разработки никто не знает, как это должно работать — надо пробовать.

                                                    А бизнес модель разработчика конструктора может строиться не на продаже новых копий (их можно отдавать бесплатно), а на сопутствующих услугах.
                                                    Например, делается что то вроде фриланс биржи по работе с конструктором, где профи помогают сделать нормальную схему БД, или доработать интерфейс / разработать специфический расчетный модуль, а разработчик конструктора забирает себе процент от оплаты.
                                                  0
                                                  «есть отдельный этап разработки конкретных бизнес-приложений на этой платформе для конкретного заказчика, который выполняют отдельные люди, хорошо знакомые не только с программированием, платформой и инструментами, но ещё и с предметной областью заказчика. Пользователи же должны лишь пользоваться.»
                                                  Нет четкой границы между прикладными программистами и пользователями. Любой «продвинутый пользователь» может добавить в той же 1С дополнительный реквизит в шапку документа. Если при этом не надо никак изменять логику проведения документа — всё прекрасно будет работать. Такие задачи на практике встречаются очень часто. И от того, что человек смог добавить дополнительное поле, программистом его называть не совсем корректно.
                                                  0
                                                  «Но тут, не так все просто, тут возникает момент-конфликт логики процесса и логики данных в бд, и как это грамотно совместить, т.к. БД у нас на текущий момент реляционные — структура жесткая(1С, magneto и.т.д.) для обхода этого ограничения используют EAV, вот поэтому в 1C и нет простого доступа к BD, ибо запросы нелогичны, но сейчас BD научились, работать с XML/JSON, тоесть по факту они уже не relation, и тут уже возможно поиграть с совмещением не совмещаемого, но с архитектурной точки зрения не все так просто.»

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

                                                  А в 1С нет доступа к базе по другой причине — они наплодили велосипедов и костылей, и сейчас это всё тяжело поддерживать. Например, у них до сих пор есть своя файловая БД, вот скорее всего из-за неё и не могут сделать нормальный доступ к базе.
                                                    0
                                                    Это Web-Access, но не всем он нужен(это не значит, что ненужен), это разные продукты, разные клиенты.
                                                    Классический пример(кейс):
                                                    каталог товаров с заранее неизвестными характеристиками товаров.
                                                    Ну, и что будем делать с реляционной моделью? по каждому чиху вызывать проектировщика бд/программиста/аналитика/тестировщика? Вот поэтому все известные мне ERP(за исключением одной Oracle E-Business Suite), не используют, реляционную модель предоставленную производителем BD, а реализуют по факту свою модель BD над BD.

                                                    Все же есть клиенты, кому нужен web-Excel, а не Access/foxpro.

                                                    Еще, есть, вобще капризные клиенты, которым нужна еще и привязка к бизнес процессу…

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


                                              0
                                              Не всегда. Есть целый ряд ситуаций, когда нужен конструктор с возможностью дописывать модули. Например, я не смогу нормально и быстро сделать UI — никогда таким не занимался. А написать небольшой расчетный модуль на SQL или на другом языке — вполне могу. И для меня конструктор очень удобен для некоторых задач.
                                              Быстро набросал некое приложение, которое сразу и заработало. Потом, по мере необходимости, дописываю различные хотелки, часть из которых делаю с помощью модулей на С# или другом языке, а часть средствами конструктора. И то, что есть возможность дописывать на универсальном языке — сильно греет душу. Всегда в крайнем случае можно пригласить другого специалиста, и он в твоем приложении допишет нужный кусочек. И не волнуешься, что конструктор не поддерживает какую-то фичу, которая понадобится, но о которой сейчас даже не подозреваешь. Стандартные языки программирования тем и хороши, что на них можно реализовать всё, что душе угодно (всё, что может делать машина Тьюринга).
                                                0

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

                                                  0
                                                  Конструктор может поддерживать глубокую доработку UI с помощью стандартных языков. И в таком случае использование конструктора тоже оправданно.
                                                  Сделал фактически прототип с помощью конструктора и несколько раз переделал его на основании замечаний пользователя. При этом UI корявый, но как-то работает. А когда все согласились, что вот так всё и должно работать — допиливается UI и всё остальное, что надо допилить. И не обязательно только с помощью инструментов конструктора.
                                                  Это, разумеется, идеализированная схема, но часто именно такой вариант является оптимальным.
                                          0
                                          Для новичков получилось слишком сложно, для продвинутых слишком узко.
                                            +1
                                            По моему мнению, вы не совсем правильно видите потребности пользователей.
                                            Исходя из моего опыта, некий конструктор нужен, но у пользователей такого конструктора нет требования «без программирования автоматизировать свои задачи».

                                            Рядовые пользователи не будут (не смогут) создавать приложения, сложность которых хоть немного превышает «базовый» уровень. То есть если структура данных требует 10 и больше таблиц — рядовой пользователь уже не может создавать такие приложения (по крайней мере, нормально работающие). Это видно на примере того же Access. Ваша фраза «с помощью Excel и Access создавались миллионы учётно-отчётных приложений» не полностью описывает ситуацию. Правильнее сказать, что создавались миллионы приложений, 95% из которых работали крайне плохо. И только 5% работали относительно нормально, так как их создатели читали справку по Access. Но чтение документации — это как раз признак ИТ специалиста. :))) А для ИТ специалистов, пусть даже начинающих, возможность (необходимость) программирования является не минусом, а плюсом.

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

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

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

                                            То есть для меня был бы интересен следующий вариант:
                                            Некий онлайн конструктор, позволяющий очень быстро создать приложение на несколько экранных форм — выбрав готовый шаблон и доработав его. Причем должны быть шаблоны как бизнес-процессов, так и типичных структур данных (карточка клиента, документ из заголовка и строк и т.п.).
                                            Бизнес логика (алгоритм) должен быть описан в графическом виде (BPMN), и база данных тоже представлена в виде простой схемы.
                                            Но должны быть возможности по более тонкой настройки — глубоко доработать базу (с помощью SQL) или написать специфический расчетный модуль, используя обычный популярный язык программирования. То есть идея с «многоступенчатых интерфейсов при создании и настройке приложения» правильная. Можно даже упростить, оставив только два уровня — «базовый» и «продвинутый». На базовом работаешь с графическим редактором BPMN, экранных форм и выбираешь готовые шаблоны кусков БД, которые опять же редактируешь в графическом интерфейсе (добавить/удалить поле, поменять тип и т.п.). А в продвинутом варианте интерфейса можно писать свой код и настраивать базу.
                                            Но надо в качестве «основы» брать не конструктор БД, а конструктор бизнес процессов. А конструктор БД — просто дополнительный (вспомогательный) модуль, основная задача которого — помочь пользователю создать схему БД из готовых кусочков и «допилить» под его задачи. Ну и создать простой отчет в графическом интерфейсе. Сложные отчеты всё равно проще будет писать на SQL, так как хоть графически выразить это всё можно, но создателю сложного отчета всё равно надо понимать разницу между левым соединением и внутренним соединением, а если человек это понимает, то и SQL выучить может.
                                            И ориентировать продукт надо на ИТ специалистов, хотя можно называть их «продвинутыми пользователями». То есть людей, которые имеют некий базовый уровень знаний в области ИТ и готовы при необходимости самостоятельно изучить новую для себя область. Например, освоить бейсик или прочитать статью о принципах создания БД.
                                              +3
                                              Приветствуем коллег по цеху:) Мы в Orienteer (open source Business Application Platform) тоже сталкиваемся с освещенными проблемами.
                                              Но мне кажется, что основную проблему вы лишь затронули: «Бизнес натягивать на систему, или систему на бизнес?». Другими словами: что лучше — супер гибкий конструктор или же преднастроенная для конкретной предметной области система.
                                              Для себя мы сделали вполне очевидный вывод: все очень сильно зависит от компании. Если фирма маленькая или только входит в какую-то отрасль, то здесь системы где УЖЕ есть необходимая предметная область, справочные таблицы и т.д. — значительно более выйгрышны. А если компания хорошо себя чувствует в своей отрасли, если ее бизнес процессы работают как по часам, то ей как-то все равно на то, что уже было «предмоделировано» — такой компании надо продавать именно гибкость и настраиваемость системы.

                                              И еще момент: сейчас хайп по облакам и SaaS как-то сходит на нет в корпоративном секторе. Компании стремяться уже иметь своё приватное облако (пусть даже и арендованное, но своё), в котором бы они могли бы размещать подобные облачные вещи. Как у вас дела обстоят с коробочной версией или же версией для приватных облаков? Для нас решением оказался docker. Docker — это прям откровение на фоне того, что было раньше:)
                                                0
                                                «А если компания хорошо себя чувствует в своей отрасли, если ее бизнес процессы работают как по часам, то ей как-то все равно на то, что уже было «предмоделировано» — такой компании надо продавать именно гибкость и настраиваемость системы.»
                                                Обычно у таких компаний УЖЕ есть некое решение, и от конструктора им требуется не гибкость и настраиваемость, а хорошие возможности по интеграции.
                                                Гибкость нужна для создания аналога уже существующего решения. Но если оно уже есть — зачем его переписывать? А вот для «расширения» существующего решения часто удобнее использовать отдельный софт, и вот тут то конструктор и пригодится.
                                                  0
                                                  «Обычно у таких компаний УЖЕ есть некое решение, и от конструктора им требуется не гибкость и настраиваемость, а хорошие возможности по интеграции.» — Хорошие возможности по интеграции это неотъемлемо от конструктора:) Такие системы им нужны обычно для преобразования существующей инфраструктуры. Да — системы есть, но зоопарк надоедает: и чем больше ты как компания, тем сильнее это давит. Более того: если нужно новое IT решение, а все существующие на рынке «не то», то надо строить ее самому. И тут встает дилемма: либо писать самому, либо воспользоваться как раз-таки конструктором — то бишь основанием, которое позволяет быстро получить результат при сравнительно небольших вложениях.
                                                0
                                                Мы тоже уже 8-й год пилим онлайн конструктор веб-форм и баз данных MyTaskHelper.

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

                                                В комментариях нашел кучу классных идей, так что спасибо и автору поста и комментаторам.

                                                Удачи в развитии сервиса!
                                                  0
                                                  Конструкторы мобильных приложений, к сожалению, требуют реально высоких компетенций у компаний. Это я сужу по нашим заказчикам (https://appropio.com)…

                                                  Only users with full accounts can post comments. Log in, please.