«А если компания хорошо себя чувствует в своей отрасли, если ее бизнес процессы работают как по часам, то ей как-то все равно на то, что уже было «предмоделировано» — такой компании надо продавать именно гибкость и настраиваемость системы.»
Обычно у таких компаний УЖЕ есть некое решение, и от конструктора им требуется не гибкость и настраиваемость, а хорошие возможности по интеграции.
Гибкость нужна для создания аналога уже существующего решения. Но если оно уже есть — зачем его переписывать? А вот для «расширения» существующего решения часто удобнее использовать отдельный софт, и вот тут то конструктор и пригодится.
По моему мнению, вы не совсем правильно видите потребности пользователей.
Исходя из моего опыта, некий конструктор нужен, но у пользователей такого конструктора нет требования «без программирования автоматизировать свои задачи».
Рядовые пользователи не будут (не смогут) создавать приложения, сложность которых хоть немного превышает «базовый» уровень. То есть если структура данных требует 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)
Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.
На вопрос «Что делать?» уже ответили — сменить страну проживания, хотя бы «виртуально». :)))
Например — настраиваем VPN до зарубежного сервера и уже оттуда выходим в инет.
В сети масса статей, как подобные вещи делаются.
«Если токарь выдает 100% качественных деталей вместо положенных по технологии 90%, то он будет лишние 10% времени бездельничать. А на заводе — это хуже, чем если он будет 20% брака выпускать.»
А можно пример такого завода или техпроцесса? Где 10% брака хуже, чем 0% брака. Ну или когда наличие 9 качественных и одной некачественной детали лучше, чем наличие 10 качественных деталей.
Станьте ёжиками! :)
«Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.»
Такое ТЗ может появиться после Обследования, Анализа и Дизайна, а это 40-60% всего проекта внедрения.
Если внедрять типовую Бухгалтерию с переделкой пары печатных форм — да, можно такое ТЗ написать ДО старта проекта. Но если что-то более объемное — такое ТЗ можно написать только после выполнения большей части работ.
И как проконтролировать, что исполнитель именно ТЗ пишет? :)
Иногда, чтобы написать пару абзацев, надо неделю ковыряться в задаче… И при этом ты ведь часто ничего, что может увидеть (проконтролировать) посторонний, не делаешь. Рисуешь что-то на доске — как другой человек поймет, это ты пытаешься структуру данных набросать, или имитируешь деятельность?
Это — самая проблемная часть всех контролей. Если есть хорошее и подробное ТЗ — то можно по нему просто писать код и замерять время написания. Но это работает в простых случаях.
А если надо написать нечто, о чем у всех очень смутное ощущение (у заказчика нет необходимых технических знаний, чтобы продумать, как все должно работать) — то много времени уйдет на придумывание алгоритма, а само написание кода займет относительно мало времени.
Я лично знаю нескольких бывших и текущих работников Big4, причем некоторых (жену) совсем близко знаю. :)
Утверждение о том, что сотрудники четверки целенаправленно массово дают плохие советы — не соответствует действительности.
Недостаточное качество аудита / консалтинга объясняется намного проще. :) Тот, кто заказывает музыку, не заинтересован в высоком качестве, или просто не способен отличить качественную услугу от некачественной. Поэтому консалтинговые / аудиторские конторы в первую прокачивают имидж (понты), а реальную работу в большинстве случаев делают вчерашние студенты с соответствующим уровнем квалификации и понятным результатом.
И, кстати, рядовые аудиторы (вчерашние студенты) достаточно часто находят «нестыковки», которые потом чаще всего «решаются» в переговорах финдира клиента с менеджером / партнером четверки.
И при всем при этом качество Биг4 обычно существенно выше, чем качество услуг локальных фирм.
Обычно у таких компаний УЖЕ есть некое решение, и от конструктора им требуется не гибкость и настраиваемость, а хорошие возможности по интеграции.
Гибкость нужна для создания аналога уже существующего решения. Но если оно уже есть — зачем его переписывать? А вот для «расширения» существующего решения часто удобнее использовать отдельный софт, и вот тут то конструктор и пригодится.
Исходя из моего опыта, некий конструктор нужен, но у пользователей такого конструктора нет требования «без программирования автоматизировать свои задачи».
Рядовые пользователи не будут (не смогут) создавать приложения, сложность которых хоть немного превышает «базовый» уровень. То есть если структура данных требует 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)
Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.
Было весело… :)))
«Любая сложная задача имеет простое, легкое для понимания неправильное решение.» © Артур Блох
Например — настраиваем VPN до зарубежного сервера и уже оттуда выходим в инет.
В сети масса статей, как подобные вещи делаются.
По этим терминам аналогичная путаница.
А можно пример такого завода или техпроцесса? Где 10% брака хуже, чем 0% брака. Ну или когда наличие 9 качественных и одной некачественной детали лучше, чем наличие 10 качественных деталей.
«Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.»
Такое ТЗ может появиться после Обследования, Анализа и Дизайна, а это 40-60% всего проекта внедрения.
Если внедрять типовую Бухгалтерию с переделкой пары печатных форм — да, можно такое ТЗ написать ДО старта проекта. Но если что-то более объемное — такое ТЗ можно написать только после выполнения большей части работ.
Иногда, чтобы написать пару абзацев, надо неделю ковыряться в задаче… И при этом ты ведь часто ничего, что может увидеть (проконтролировать) посторонний, не делаешь. Рисуешь что-то на доске — как другой человек поймет, это ты пытаешься структуру данных набросать, или имитируешь деятельность?
А если надо написать нечто, о чем у всех очень смутное ощущение (у заказчика нет необходимых технических знаний, чтобы продумать, как все должно работать) — то много времени уйдет на придумывание алгоритма, а само написание кода займет относительно мало времени.
Утверждение о том, что сотрудники четверки целенаправленно массово дают плохие советы — не соответствует действительности.
Недостаточное качество аудита / консалтинга объясняется намного проще. :) Тот, кто заказывает музыку, не заинтересован в высоком качестве, или просто не способен отличить качественную услугу от некачественной. Поэтому консалтинговые / аудиторские конторы в первую прокачивают имидж (понты), а реальную работу в большинстве случаев делают вчерашние студенты с соответствующим уровнем квалификации и понятным результатом.
И, кстати, рядовые аудиторы (вчерашние студенты) достаточно часто находят «нестыковки», которые потом чаще всего «решаются» в переговорах финдира клиента с менеджером / партнером четверки.
И при всем при этом качество Биг4 обычно существенно выше, чем качество услуг локальных фирм.