Pull to refresh

Comments 44

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

UFO just landed and posted this here

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

Кстати, это (функционал, отсутствующий в конструкторе) один из очень важных вопросов. Когда создатели конструктора начинают считать себя самыми умными и заставляют работать только с помощью инструментов конструктора. Типичный пример 1С — нельзя в самом 1С работать напрямую с базой данных через SQL, нельзя создавать свои структуры данных напрямую в БД и тому подобное.
Таких конструкторов надо по максимуму избегать. Создатель конструктора всё равно не сможет втиснуть в конструктор все возможности СУБД или стандартного языка программирования. И отсутствие возможности использовать «низкоуровневые» средства очень дорого обходится в некоторых случаях. А случаи такие случаются намного чаще, чем многие думают. :)))
UFO just landed and posted this here

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


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

UFO just landed and posted this here

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи в развитии сервиса!
Sign up to leave a comment.

Articles