Посмотрел видео по ссылке — ничего нового не услышал. Кстати, в целом со всем согласен. :)
Я писал о другом. Мне как раз и захотелось найти нормальные статистические данные об осложнениях после прививок без субъективных оценок не всегда квалифицированных врачей. Я ожидал, что легко получится найти данные примерно такого типа — выбрали 100 тысяч человек и совместили данные о датах всех перенесенных этими людьми болезней болезней (дата обращения к врачу, диагноз) за 2 года с графиком прививок за тот же период.
Даже если некоторые диагнозы поставлены неверно или некорректно определено наличие / отсутствие связи между прививкой и заболеванием — большая правильно сделанная выборка сгладит эти неточности и покажет реальный уровень риска осложнений.
И я такого исследования найти не смог. Может, разумеется, плохо искал. Но сразу возникает вопрос — почему на сайте того же ВОЗ достаточно много ссылок на разные исследования, опровергающие связь прививок и склероза, артрита и много уверений в безопасности прививок, а ссылки на подобные исследования на видном месте нет?
Так я и слушал врачей. :) И именно врачи в неофициальной беседе предупредили, что опасность от прививок, по их мнению, больше, чем многие думают и чем пытаются нас убедить их производители.
Но вообще ваш аргумент нелогичен. То, что я не разбираюсь в медицине, не значит, что я не разбираюсь в статистике.
Есть огромное количеств фактических данных о историях болезней — кто, когда и чем болел. Также можно найти информацию, кто когда и какой именно вакциной прививался. И сделать анализ этих данных (есть корелляция между этими событиями или нет, и если есть — то какая именно) — не очень сложная и дорогая задача. Более того, я ожидал, что легко найду ссылки на сотни таких исследований с нормальным описанием методики (как формировалась выборка и т.п.) и полученных результатах — тема ведь многих волнует. И удивился, когда нашел данные о всего нескольких исследованиях и при этом даже о них нет (или не смог найти) нормального описания методики формирования выборок. И вот тут то и закрались сомнения — а насколько всё то, что нам рассказывают о прививках, имеет научное обоснование? Пусть даже не механизм действия прививок (как именно работает иммунитет, хорошо разобрались ближе к концу 20 века, а прививки массово начали делать в начале 20 века), но хотя бы статистические доказательства их эффективности и безопасности.
Попробуйте сами потратить немного времени и найти исследования по прививкам, которые соответствуют научным критериям. И после этого обсудим. :)
Пример с вакцинами совсем не так однозначен, как вы пытаетесь показать. Вообще исследований о эффективности вакцин и о возможных негативных последствиях для здоровья — относительно мало, а те, что есть — не все надежны с научной точки зрения.
Попробуйте найти описание исследований с контрольными группами, двойным слепым методом и статистически значимым количеством участников. Таких исследований почему-то намного меньше, чем ожидаешь.
Хотя лично у меня главная претензия к вакцинации (а скорее к бизнесу фармкомпаний по производству вакцин) лежит в немного иной области.
Даже самые горячие сторонники вакцинации признают, что как минимум часть вакцин в отдельных (редких) случаях должна давать негативные последствия для здоровья вакцинируемых людей. Предполагается, что это небольшая цена за то, что прекратились эпидемии.
Но попробуйте найти нормальную статистику о таких случаях, с описанием методик сбора данных. У меня не получилось. Но я ладно, к медицине и фармакологии не имею отношения, но и у знакомых, которые работают врачами и фармацевтами — тоже не получилось найти эти данные. И насколько они знают, просто не существует каких то четких инструкций / процедур / стандартов, согласно которым можно (нужно) связывать проблему со здоровьем с применением вакцины (по крайней мере в России и Украине).
Я лично знаю два случая с моими знакомыми, когда у детей существенные проблемы со здоровьем начались в течении нескольких дней после вакцинации. И их мамы однозначно связывают эти проблемы с вакцинацией. Учитывая, что одна из этих мам — фармацевт, а вторая — врач, эти случаи заставляют задуматься о реальном уровне безопасности вакцин. Ведь если вакцинация очень безопасна, маловероятно, что среди лично знакомых людей столкнешься сразу с двумя случаями. И настораживает, что в этих случаях не только никто не признал, что проблемы возникли вследствии вакцинации (действительно, тут может не быть причинно-следственной связи, хотя короткий временной промежуток настораживает), но и не было ВООБЩЕ никакого расследования, есть связь между вакцинацией и заболеванием в этом случае, или нет. То есть ребенок заболел, его начали лечить, но никто не пытался выяснить, а почему именно он заболел и не связано ли это с вакцинацией.
Еще раз уточняю — речь идет о детях врача и фармацевта (с высшим образованием и работающие по специальности), которых лично знаю.
Поэтому фраза «действительные факты очень часто опережаются ложными, но более привлекательно упакованными данными» применительно к вакцинам звучит достаточно двусмысленно. Ведь создавались тысячи разных вакцин (в том числе и с живыми микроорганизмами, которые не могут быть полностью безопасны по определению) и применялись в сотнях миллионов случаев — и при этом относительно мало надежных данных о эффективности и безопасности этих вакцин.
«есть отдельный этап разработки конкретных бизнес-приложений на этой платформе для конкретного заказчика, который выполняют отдельные люди, хорошо знакомые не только с программированием, платформой и инструментами, но ещё и с предметной областью заказчика. Пользователи же должны лишь пользоваться.»
Нет четкой границы между прикладными программистами и пользователями. Любой «продвинутый пользователь» может добавить в той же 1С дополнительный реквизит в шапку документа. Если при этом не надо никак изменять логику проведения документа — всё прекрасно будет работать. Такие задачи на практике встречаются очень часто. И от того, что человек смог добавить дополнительное поле, программистом его называть не совсем корректно.
«Но тут, не так все просто, тут возникает момент-конфликт логики процесса и логики данных в бд, и как это грамотно совместить, т.к. БД у нас на текущий момент реляционные — структура жесткая(1С, magneto и.т.д.) для обхода этого ограничения используют EAV, вот поэтому в 1C и нет простого доступа к BD, ибо запросы нелогичны, но сейчас BD научились, работать с XML/JSON, тоесть по факту они уже не relation, и тут уже возможно поиграть с совмещением не совмещаемого, но с архитектурной точки зрения не все так просто.»
По моему мнению, именно для бизнес задач не надо ничего изобретать, а надо использовать реляционные БД, которые в основном под эти задачи и создавались. И жесткая структура для бизнес данных является плюсом — иначе будут сложности с анализом. Единственная проблема — «кухарка» не сможет сделать нормальную схему БД (нужны знания по теории БД). Но тут можно в значительной степени решить проблему с помощью библиотеки готовых шаблонов («документ» в конфигурации 1С создает таблички в БД по определенному шаблону) + привлечения нормальных специалистов для рефакторинга базы на более поздних этапах жизненного цикла создаваемого софта, когда структура приложения более менее устоялась.
А в 1С нет доступа к базе по другой причине — они наплодили велосипедов и костылей, и сейчас это всё тяжело поддерживать. Например, у них до сих пор есть своя файловая БД, вот скорее всего из-за неё и не могут сделать нормальный доступ к базе.
Конструктор может поддерживать глубокую доработку UI с помощью стандартных языков. И в таком случае использование конструктора тоже оправданно.
Сделал фактически прототип с помощью конструктора и несколько раз переделал его на основании замечаний пользователя. При этом UI корявый, но как-то работает. А когда все согласились, что вот так всё и должно работать — допиливается UI и всё остальное, что надо допилить. И не обязательно только с помощью инструментов конструктора.
Это, разумеется, идеализированная схема, но часто именно такой вариант является оптимальным.
Почти у каждой компании есть устоявшиеся процессы, которые и составляют 90-98% операционной деятельности, и новые процессы, по которым нет четких правил.
Для новых процессов и нужны конструкторы, которые позволяют с минимальными затратами разработать софт (пусть с не очень удобным UI или немного кривой схемой БД). Главное, чтобы этот софт можно было легко переделывать. Ведь при начале разработки никто не знает, как это должно работать — надо пробовать.
А бизнес модель разработчика конструктора может строиться не на продаже новых копий (их можно отдавать бесплатно), а на сопутствующих услугах.
Например, делается что то вроде фриланс биржи по работе с конструктором, где профи помогают сделать нормальную схему БД, или доработать интерфейс / разработать специфический расчетный модуль, а разработчик конструктора забирает себе процент от оплаты.
Не всегда. Есть целый ряд ситуаций, когда нужен конструктор с возможностью дописывать модули. Например, я не смогу нормально и быстро сделать UI — никогда таким не занимался. А написать небольшой расчетный модуль на SQL или на другом языке — вполне могу. И для меня конструктор очень удобен для некоторых задач.
Быстро набросал некое приложение, которое сразу и заработало. Потом, по мере необходимости, дописываю различные хотелки, часть из которых делаю с помощью модулей на С# или другом языке, а часть средствами конструктора. И то, что есть возможность дописывать на универсальном языке — сильно греет душу. Всегда в крайнем случае можно пригласить другого специалиста, и он в твоем приложении допишет нужный кусочек. И не волнуешься, что конструктор не поддерживает какую-то фичу, которая понадобится, но о которой сейчас даже не подозреваешь. Стандартные языки программирования тем и хороши, что на них можно реализовать всё, что душе угодно (всё, что может делать машина Тьюринга).
Кстати, это (функционал, отсутствующий в конструкторе) один из очень важных вопросов. Когда создатели конструктора начинают считать себя самыми умными и заставляют работать только с помощью инструментов конструктора. Типичный пример 1С — нельзя в самом 1С работать напрямую с базой данных через SQL, нельзя создавать свои структуры данных напрямую в БД и тому подобное.
Таких конструкторов надо по максимуму избегать. Создатель конструктора всё равно не сможет втиснуть в конструктор все возможности СУБД или стандартного языка программирования. И отсутствие возможности использовать «низкоуровневые» средства очень дорого обходится в некоторых случаях. А случаи такие случаются намного чаще, чем многие думают. :)))
«А если компания хорошо себя чувствует в своей отрасли, если ее бизнес процессы работают как по часам, то ей как-то все равно на то, что уже было «предмоделировано» — такой компании надо продавать именно гибкость и настраиваемость системы.»
Обычно у таких компаний УЖЕ есть некое решение, и от конструктора им требуется не гибкость и настраиваемость, а хорошие возможности по интеграции.
Гибкость нужна для создания аналога уже существующего решения. Но если оно уже есть — зачем его переписывать? А вот для «расширения» существующего решения часто удобнее использовать отдельный софт, и вот тут то конструктор и пригодится.
По моему мнению, вы не совсем правильно видите потребности пользователей.
Исходя из моего опыта, некий конструктор нужен, но у пользователей такого конструктора нет требования «без программирования автоматизировать свои задачи».
Рядовые пользователи не будут (не смогут) создавать приложения, сложность которых хоть немного превышает «базовый» уровень. То есть если структура данных требует 10 и больше таблиц — рядовой пользователь уже не может создавать такие приложения (по крайней мере, нормально работающие). Это видно на примере того же Access. Ваша фраза «с помощью Excel и Access создавались миллионы учётно-отчётных приложений» не полностью описывает ситуацию. Правильнее сказать, что создавались миллионы приложений, 95% из которых работали крайне плохо. И только 5% работали относительно нормально, так как их создатели читали справку по Access. Но чтение документации — это как раз признак ИТ специалиста. :))) А для ИТ специалистов, пусть даже начинающих, возможность (необходимость) программирования является не минусом, а плюсом.
Другое дело, что есть требование максимально облегчить процесс программирования. Для бизнес задач редко требуются возможности, отличные от базовых. И желательно сделать программирование простых алгоритмов и распространенных структур данных максимально простым и наглядным.
Для себя я нашел приемлемое средство для автоматизации (и не одно) — это BPM системы (Bonita, BizAgi). В них достаточно легко разработать простое бизнес приложение, которое в дальнейшем можно развивать (усложнять). Другое дело, что надо самому разворачивать сервер, а это не всегда удобно.
Возможно, вам стоит создать нечто аналогичное по функциональности, но работающее онлайн. Это было бы интересно.
А онлайн конструктор баз данных… Все люди делятся на два типа. Одни могут спроектировать базу данных, и при этом им конструктор как таковой не особо нужен. Другие не могут её создать (не хватает знаний), и конструктор им в этом не поможет. Для таких пользователей может быть полезно наличие готовых «шаблонов» баз данных (вернее их кусочков), из которых можно «собрать» свою базу. Но опять же — создавать приложения будут не рядовые пользователи, а ИТ специалисты. Иногда их называют продвинутыми пользователями, но сути это не меняет. То есть конструктор БД нужен только как вспомогательный инструмент — в графическом интерфейсе добавлять поля в таблички проще. Важнее наличие готовых качественных шаблонов для типовых ситуаций (справочник, документ и т.п.) — чтобы человек, который не слышал о нормализации БД, мог собрать из кусочков (готовых шаблонов) не очень кривую базу.
То есть для меня был бы интересен следующий вариант:
Некий онлайн конструктор, позволяющий очень быстро создать приложение на несколько экранных форм — выбрав готовый шаблон и доработав его. Причем должны быть шаблоны как бизнес-процессов, так и типичных структур данных (карточка клиента, документ из заголовка и строк и т.п.).
Бизнес логика (алгоритм) должен быть описан в графическом виде (BPMN), и база данных тоже представлена в виде простой схемы.
Но должны быть возможности по более тонкой настройки — глубоко доработать базу (с помощью SQL) или написать специфический расчетный модуль, используя обычный популярный язык программирования. То есть идея с «многоступенчатых интерфейсов при создании и настройке приложения» правильная. Можно даже упростить, оставив только два уровня — «базовый» и «продвинутый». На базовом работаешь с графическим редактором BPMN, экранных форм и выбираешь готовые шаблоны кусков БД, которые опять же редактируешь в графическом интерфейсе (добавить/удалить поле, поменять тип и т.п.). А в продвинутом варианте интерфейса можно писать свой код и настраивать базу.
Но надо в качестве «основы» брать не конструктор БД, а конструктор бизнес процессов. А конструктор БД — просто дополнительный (вспомогательный) модуль, основная задача которого — помочь пользователю создать схему БД из готовых кусочков и «допилить» под его задачи. Ну и создать простой отчет в графическом интерфейсе. Сложные отчеты всё равно проще будет писать на SQL, так как хоть графически выразить это всё можно, но создателю сложного отчета всё равно надо понимать разницу между левым соединением и внутренним соединением, а если человек это понимает, то и SQL выучить может.
И ориентировать продукт надо на ИТ специалистов, хотя можно называть их «продвинутыми пользователями». То есть людей, которые имеют некий базовый уровень знаний в области ИТ и готовы при необходимости самостоятельно изучить новую для себя область. Например, освоить бейсик или прочитать статью о принципах создания БД.
Так диаграммы и нужны в первую очередь для того, чтобы на них смотреть «вручную».
Описание бизнес процесса надо сначала придумать (создать), и только потом верифицировать, запускать на выполнение и т.п. И придумывают описание БП «вручную». Я допускаю, что есть люди, которые могут создать описание БП в виде матрицы 1000*1000. Но таких явно ОЧЕНЬ мало. А все остальные используют BPMN.
Даже простой БП может содержать больше 100 значений параметров. Проанализировать матрицу 100*100 человеку уже крайне тяжело. А многие реальные процессы могут содержать тысячи значений параметров.
Так что матрица заменить BPMN не может. Ведь с диаграммами в первую очередь работают люди, а они не могут воспринимать гигантские матрицы.
Разве что жить в них могут. :)))
Для объекта — понятно, как можно составить матрицу.
Но как быть с бизнес процессом в целом? БП может разветвляться и ветви выполняются без синхронизации. Например, синхронизация в самом конце. Ведь для такого процесса понадобится ОЧЕНЬ большая матрица… И представить процесс как набор матриц отдельных шагов или объектов наверно не получится. По крайней мере я не представляю, как.
Вы как то резко испортили моё мнение о вашем продукте, которого я вообще не видел. Получается, что вы или не знаете, что такое ERP / CRM, или используете некорректные названия для своих продуктов.
Предположим, некая компания внедрила ваш CRM c модулем склада. Через некоторое время осознали, что CRM и ERP — это немного разные буквы, и нужна также функциональность ERP. Начали внедрять еще и ERP систему.
Что в таком случае будет со складом?
Как то странно выглядит логика удаления таска 2.
Мне кажется, в версии 2 (промежуточной) надо от таска 2 переходить не к завершению БП, а к таску 3. Иначе нарушается логика всего бизнес процесса.
Дополню — написание именно «формального» ТЗ в таких ситуациях является лишним.
ТЗ пишется, только в неявном виде.
Для отчета в качестве ТЗ выступает сам отчет (тестовая версия) + пожелания по добавлению / изменению полей.
Или это может быть тестовая версия кода, который реализует некую относительно простую функциональность + пожелания пользователей. Но с кодом сложнее — если может затронуть другие модули, то очень желательно написать формальное ТЗ.
Например для небольшого отчета мне проще после общего описания хотелок сразу написать тестовый вариант. После этого все смотрят на отчет с живыми данными (это часто важно) и озвучивают дополнительные пожелания. Часть пожеланий сразу отклоняется, остальные реализовываются.
Написание ТЗ в таких случаях — лишняя работа. Ведь для грамотного ТЗ всё равно надо проанализировать структуру данных — что и в каком виде можно получить. То есть фактически для написания ТЗ надо создать отчет :)
Только что закончили основной этап проекта по созданию куба БЕЗ ТЗ. Некий вариант «заказчик не знает как должно быть», но с добавлением, что и исполнитель не знает, как это можно сделать. :)
Успешно.
Это был АДЪ :)
НО.
ТЗ просто не получалось написать.
Мы не смогли найти специалистов, которые обладают нужными знаниями для написания ТЗ.
Общая задача:
Надо разложить себестоимость продаж (фактически — отдельные фин проводки) на составные элементы с точностью до инвойса от поставщика товаров / услуг. Также нужны аналогичные отчеты по себестоимости, которая отнесена на конкретные партии закупленного материала на всем пути от завода до покупателя.
Куб предназначен в первую очередь для финансистов. Данные надо получать из ERP — MS Dynamics NAV. При этом данные надо ОЧЕНЬ сильно трансформировать перед загрузкой в куб.
То есть человек, который мог бы написать ТЗ, должен:
— иметь знания в области финансов (финансисты понимали, что им надо, но объяснить чистым ИТишникам не получалось)
— иметь знания, как работает MS Dynamics NAV (один из самых сложных модулей — расчет себестоимости)
— разбираться, как можно преобразовать данные в нужный формат
— разбираться в кубах (SSAS)
Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.
Я писал о другом. Мне как раз и захотелось найти нормальные статистические данные об осложнениях после прививок без субъективных оценок не всегда квалифицированных врачей. Я ожидал, что легко получится найти данные примерно такого типа — выбрали 100 тысяч человек и совместили данные о датах всех перенесенных этими людьми болезней болезней (дата обращения к врачу, диагноз) за 2 года с графиком прививок за тот же период.
Даже если некоторые диагнозы поставлены неверно или некорректно определено наличие / отсутствие связи между прививкой и заболеванием — большая правильно сделанная выборка сгладит эти неточности и покажет реальный уровень риска осложнений.
И я такого исследования найти не смог. Может, разумеется, плохо искал. Но сразу возникает вопрос — почему на сайте того же ВОЗ достаточно много ссылок на разные исследования, опровергающие связь прививок и склероза, артрита и много уверений в безопасности прививок, а ссылки на подобные исследования на видном месте нет?
Но вообще ваш аргумент нелогичен. То, что я не разбираюсь в медицине, не значит, что я не разбираюсь в статистике.
Есть огромное количеств фактических данных о историях болезней — кто, когда и чем болел. Также можно найти информацию, кто когда и какой именно вакциной прививался. И сделать анализ этих данных (есть корелляция между этими событиями или нет, и если есть — то какая именно) — не очень сложная и дорогая задача. Более того, я ожидал, что легко найду ссылки на сотни таких исследований с нормальным описанием методики (как формировалась выборка и т.п.) и полученных результатах — тема ведь многих волнует. И удивился, когда нашел данные о всего нескольких исследованиях и при этом даже о них нет (или не смог найти) нормального описания методики формирования выборок. И вот тут то и закрались сомнения — а насколько всё то, что нам рассказывают о прививках, имеет научное обоснование? Пусть даже не механизм действия прививок (как именно работает иммунитет, хорошо разобрались ближе к концу 20 века, а прививки массово начали делать в начале 20 века), но хотя бы статистические доказательства их эффективности и безопасности.
Попробуйте сами потратить немного времени и найти исследования по прививкам, которые соответствуют научным критериям. И после этого обсудим. :)
Попробуйте найти описание исследований с контрольными группами, двойным слепым методом и статистически значимым количеством участников. Таких исследований почему-то намного меньше, чем ожидаешь.
Хотя лично у меня главная претензия к вакцинации (а скорее к бизнесу фармкомпаний по производству вакцин) лежит в немного иной области.
Даже самые горячие сторонники вакцинации признают, что как минимум часть вакцин в отдельных (редких) случаях должна давать негативные последствия для здоровья вакцинируемых людей. Предполагается, что это небольшая цена за то, что прекратились эпидемии.
Но попробуйте найти нормальную статистику о таких случаях, с описанием методик сбора данных. У меня не получилось. Но я ладно, к медицине и фармакологии не имею отношения, но и у знакомых, которые работают врачами и фармацевтами — тоже не получилось найти эти данные. И насколько они знают, просто не существует каких то четких инструкций / процедур / стандартов, согласно которым можно (нужно) связывать проблему со здоровьем с применением вакцины (по крайней мере в России и Украине).
Я лично знаю два случая с моими знакомыми, когда у детей существенные проблемы со здоровьем начались в течении нескольких дней после вакцинации. И их мамы однозначно связывают эти проблемы с вакцинацией. Учитывая, что одна из этих мам — фармацевт, а вторая — врач, эти случаи заставляют задуматься о реальном уровне безопасности вакцин. Ведь если вакцинация очень безопасна, маловероятно, что среди лично знакомых людей столкнешься сразу с двумя случаями. И настораживает, что в этих случаях не только никто не признал, что проблемы возникли вследствии вакцинации (действительно, тут может не быть причинно-следственной связи, хотя короткий временной промежуток настораживает), но и не было ВООБЩЕ никакого расследования, есть связь между вакцинацией и заболеванием в этом случае, или нет. То есть ребенок заболел, его начали лечить, но никто не пытался выяснить, а почему именно он заболел и не связано ли это с вакцинацией.
Еще раз уточняю — речь идет о детях врача и фармацевта (с высшим образованием и работающие по специальности), которых лично знаю.
Поэтому фраза «действительные факты очень часто опережаются ложными, но более привлекательно упакованными данными» применительно к вакцинам звучит достаточно двусмысленно. Ведь создавались тысячи разных вакцин (в том числе и с живыми микроорганизмами, которые не могут быть полностью безопасны по определению) и применялись в сотнях миллионов случаев — и при этом относительно мало надежных данных о эффективности и безопасности этих вакцин.
Нет четкой границы между прикладными программистами и пользователями. Любой «продвинутый пользователь» может добавить в той же 1С дополнительный реквизит в шапку документа. Если при этом не надо никак изменять логику проведения документа — всё прекрасно будет работать. Такие задачи на практике встречаются очень часто. И от того, что человек смог добавить дополнительное поле, программистом его называть не совсем корректно.
По моему мнению, именно для бизнес задач не надо ничего изобретать, а надо использовать реляционные БД, которые в основном под эти задачи и создавались. И жесткая структура для бизнес данных является плюсом — иначе будут сложности с анализом. Единственная проблема — «кухарка» не сможет сделать нормальную схему БД (нужны знания по теории БД). Но тут можно в значительной степени решить проблему с помощью библиотеки готовых шаблонов («документ» в конфигурации 1С создает таблички в БД по определенному шаблону) + привлечения нормальных специалистов для рефакторинга базы на более поздних этапах жизненного цикла создаваемого софта, когда структура приложения более менее устоялась.
А в 1С нет доступа к базе по другой причине — они наплодили велосипедов и костылей, и сейчас это всё тяжело поддерживать. Например, у них до сих пор есть своя файловая БД, вот скорее всего из-за неё и не могут сделать нормальный доступ к базе.
Сделал фактически прототип с помощью конструктора и несколько раз переделал его на основании замечаний пользователя. При этом UI корявый, но как-то работает. А когда все согласились, что вот так всё и должно работать — допиливается UI и всё остальное, что надо допилить. И не обязательно только с помощью инструментов конструктора.
Это, разумеется, идеализированная схема, но часто именно такой вариант является оптимальным.
Для новых процессов и нужны конструкторы, которые позволяют с минимальными затратами разработать софт (пусть с не очень удобным UI или немного кривой схемой БД). Главное, чтобы этот софт можно было легко переделывать. Ведь при начале разработки никто не знает, как это должно работать — надо пробовать.
А бизнес модель разработчика конструктора может строиться не на продаже новых копий (их можно отдавать бесплатно), а на сопутствующих услугах.
Например, делается что то вроде фриланс биржи по работе с конструктором, где профи помогают сделать нормальную схему БД, или доработать интерфейс / разработать специфический расчетный модуль, а разработчик конструктора забирает себе процент от оплаты.
Быстро набросал некое приложение, которое сразу и заработало. Потом, по мере необходимости, дописываю различные хотелки, часть из которых делаю с помощью модулей на С# или другом языке, а часть средствами конструктора. И то, что есть возможность дописывать на универсальном языке — сильно греет душу. Всегда в крайнем случае можно пригласить другого специалиста, и он в твоем приложении допишет нужный кусочек. И не волнуешься, что конструктор не поддерживает какую-то фичу, которая понадобится, но о которой сейчас даже не подозреваешь. Стандартные языки программирования тем и хороши, что на них можно реализовать всё, что душе угодно (всё, что может делать машина Тьюринга).
Таких конструкторов надо по максимуму избегать. Создатель конструктора всё равно не сможет втиснуть в конструктор все возможности СУБД или стандартного языка программирования. И отсутствие возможности использовать «низкоуровневые» средства очень дорого обходится в некоторых случаях. А случаи такие случаются намного чаще, чем многие думают. :)))
Обычно у таких компаний УЖЕ есть некое решение, и от конструктора им требуется не гибкость и настраиваемость, а хорошие возможности по интеграции.
Гибкость нужна для создания аналога уже существующего решения. Но если оно уже есть — зачем его переписывать? А вот для «расширения» существующего решения часто удобнее использовать отдельный софт, и вот тут то конструктор и пригодится.
Исходя из моего опыта, некий конструктор нужен, но у пользователей такого конструктора нет требования «без программирования автоматизировать свои задачи».
Рядовые пользователи не будут (не смогут) создавать приложения, сложность которых хоть немного превышает «базовый» уровень. То есть если структура данных требует 10 и больше таблиц — рядовой пользователь уже не может создавать такие приложения (по крайней мере, нормально работающие). Это видно на примере того же Access. Ваша фраза «с помощью Excel и Access создавались миллионы учётно-отчётных приложений» не полностью описывает ситуацию. Правильнее сказать, что создавались миллионы приложений, 95% из которых работали крайне плохо. И только 5% работали относительно нормально, так как их создатели читали справку по Access. Но чтение документации — это как раз признак ИТ специалиста. :))) А для ИТ специалистов, пусть даже начинающих, возможность (необходимость) программирования является не минусом, а плюсом.
Другое дело, что есть требование максимально облегчить процесс программирования. Для бизнес задач редко требуются возможности, отличные от базовых. И желательно сделать программирование простых алгоритмов и распространенных структур данных максимально простым и наглядным.
Для себя я нашел приемлемое средство для автоматизации (и не одно) — это BPM системы (Bonita, BizAgi). В них достаточно легко разработать простое бизнес приложение, которое в дальнейшем можно развивать (усложнять). Другое дело, что надо самому разворачивать сервер, а это не всегда удобно.
Возможно, вам стоит создать нечто аналогичное по функциональности, но работающее онлайн. Это было бы интересно.
А онлайн конструктор баз данных… Все люди делятся на два типа. Одни могут спроектировать базу данных, и при этом им конструктор как таковой не особо нужен. Другие не могут её создать (не хватает знаний), и конструктор им в этом не поможет. Для таких пользователей может быть полезно наличие готовых «шаблонов» баз данных (вернее их кусочков), из которых можно «собрать» свою базу. Но опять же — создавать приложения будут не рядовые пользователи, а ИТ специалисты. Иногда их называют продвинутыми пользователями, но сути это не меняет. То есть конструктор БД нужен только как вспомогательный инструмент — в графическом интерфейсе добавлять поля в таблички проще. Важнее наличие готовых качественных шаблонов для типовых ситуаций (справочник, документ и т.п.) — чтобы человек, который не слышал о нормализации БД, мог собрать из кусочков (готовых шаблонов) не очень кривую базу.
То есть для меня был бы интересен следующий вариант:
Некий онлайн конструктор, позволяющий очень быстро создать приложение на несколько экранных форм — выбрав готовый шаблон и доработав его. Причем должны быть шаблоны как бизнес-процессов, так и типичных структур данных (карточка клиента, документ из заголовка и строк и т.п.).
Бизнес логика (алгоритм) должен быть описан в графическом виде (BPMN), и база данных тоже представлена в виде простой схемы.
Но должны быть возможности по более тонкой настройки — глубоко доработать базу (с помощью SQL) или написать специфический расчетный модуль, используя обычный популярный язык программирования. То есть идея с «многоступенчатых интерфейсов при создании и настройке приложения» правильная. Можно даже упростить, оставив только два уровня — «базовый» и «продвинутый». На базовом работаешь с графическим редактором BPMN, экранных форм и выбираешь готовые шаблоны кусков БД, которые опять же редактируешь в графическом интерфейсе (добавить/удалить поле, поменять тип и т.п.). А в продвинутом варианте интерфейса можно писать свой код и настраивать базу.
Но надо в качестве «основы» брать не конструктор БД, а конструктор бизнес процессов. А конструктор БД — просто дополнительный (вспомогательный) модуль, основная задача которого — помочь пользователю создать схему БД из готовых кусочков и «допилить» под его задачи. Ну и создать простой отчет в графическом интерфейсе. Сложные отчеты всё равно проще будет писать на SQL, так как хоть графически выразить это всё можно, но создателю сложного отчета всё равно надо понимать разницу между левым соединением и внутренним соединением, а если человек это понимает, то и SQL выучить может.
И ориентировать продукт надо на ИТ специалистов, хотя можно называть их «продвинутыми пользователями». То есть людей, которые имеют некий базовый уровень знаний в области ИТ и готовы при необходимости самостоятельно изучить новую для себя область. Например, освоить бейсик или прочитать статью о принципах создания БД.
Описание бизнес процесса надо сначала придумать (создать), и только потом верифицировать, запускать на выполнение и т.п. И придумывают описание БП «вручную». Я допускаю, что есть люди, которые могут создать описание БП в виде матрицы 1000*1000. Но таких явно ОЧЕНЬ мало. А все остальные используют BPMN.
Так что матрица заменить BPMN не может. Ведь с диаграммами в первую очередь работают люди, а они не могут воспринимать гигантские матрицы.
Разве что жить в них могут. :)))
Но как быть с бизнес процессом в целом? БП может разветвляться и ветви выполняются без синхронизации. Например, синхронизация в самом конце. Ведь для такого процесса понадобится ОЧЕНЬ большая матрица… И представить процесс как набор матриц отдельных шагов или объектов наверно не получится. По крайней мере я не представляю, как.
Что в таком случае будет со складом?
Мне кажется, в версии 2 (промежуточной) надо от таска 2 переходить не к завершению БП, а к таску 3. Иначе нарушается логика всего бизнес процесса.
ТЗ пишется, только в неявном виде.
Для отчета в качестве ТЗ выступает сам отчет (тестовая версия) + пожелания по добавлению / изменению полей.
Или это может быть тестовая версия кода, который реализует некую относительно простую функциональность + пожелания пользователей. Но с кодом сложнее — если может затронуть другие модули, то очень желательно написать формальное ТЗ.
Написание ТЗ в таких случаях — лишняя работа. Ведь для грамотного ТЗ всё равно надо проанализировать структуру данных — что и в каком виде можно получить. То есть фактически для написания ТЗ надо создать отчет :)
Успешно.
Это был АДЪ :)
НО.
ТЗ просто не получалось написать.
Мы не смогли найти специалистов, которые обладают нужными знаниями для написания ТЗ.
Общая задача:
Надо разложить себестоимость продаж (фактически — отдельные фин проводки) на составные элементы с точностью до инвойса от поставщика товаров / услуг. Также нужны аналогичные отчеты по себестоимости, которая отнесена на конкретные партии закупленного материала на всем пути от завода до покупателя.
Куб предназначен в первую очередь для финансистов. Данные надо получать из ERP — MS Dynamics NAV. При этом данные надо ОЧЕНЬ сильно трансформировать перед загрузкой в куб.
То есть человек, который мог бы написать ТЗ, должен:
— иметь знания в области финансов (финансисты понимали, что им надо, но объяснить чистым ИТишникам не получалось)
— иметь знания, как работает MS Dynamics NAV (один из самых сложных модулей — расчет себестоимости)
— разбираться, как можно преобразовать данные в нужный формат
— разбираться в кубах (SSAS)
Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.
Было весело… :)))