Хочу проверить свои предположения. Посмотрел, что вашему сервису один год. Судя по количеству задач и коммитов у вас 3 разработчика и один живой тестировщик. Я сильно ошибся?
Вдогонку. Видимо, Вы невнимательно читаете цепочку разговора. Мы с shai_hulud пытаемся обсудить причины захламления ЕРП систем, вскользь упомянутую в этом выступлении. Мои доводы о причинах захламления я указал в другой статье, ссылку на которую привел (о чем собственно и сказал в выступлении).
Уважаемый braindamaged, специально для вас выписываю заголовки статьи:
1. В процессе покупки, ключевые решения принимают люди, которые не будут пользоваться софтом.
2. Во время внедрения ключевые решения принимают люди, которые не будут пользоваться софтом.
3. Информационные системы отражают бизнес-процесс компании, наложенный на универсальную болванку коробочной версии.
В: Почему бы заказчикам не покупать софт правильно, покупая 90% готового функционала?
В: А почему бы не объединять и не согласовывать требования?
Если вы решите статью прочесть, то увидите что и внутри статьи речь идет преимущественно о анализе требований разными людьми на проекте и совокупностью их решений.
Коллега, мы ведь говорим о пункте 10? Почему ЕРП системы захламляются? Вы предположили, что я не понимаю причин. Я дал ссылку на статью, где эти причины излагаю.
Вы написали, причину, которую я якобы не указал — это сбор бизнес-требований.
Однако большинство пунктов этой статьи посвящены сбору бизнес-требований. Я спросил, какой процесс не был учтен.
Вы пишете: сбор, выявление, преобразование в физическую модель.
ПРАВИЛЬНО ЛИ Я ПОНИМАЮ, ЧТО ЭТО НАЗВАНИЕ ПРОЦЕССОВ, КОТОРЫЕ Я НЕ УЧЕЛ В ПРИЧИНАХ?
В ПОЛОВИНА статьи посвящена сбору и выявлению требований. И вы все еще так и не сказали, как эти процессы влияют на захламление/очистку системы, кроме тех аспектов что я УЖЕ написал в статье.
Или я один из нас двоих слежу за нитью дискуссии? Если нет желания дискутировать, тогда стоило ли Вам ее продолжать?
Ок. Вашу позицию я понял: «Нужно анализировать бизнес-требования». Как это относится к теме статьи — вы так и не пояснили.
Наверное, вы хороший консалтинговый специалист.
О, кстати, сорри за оффтоп. Посмотрел, где Вы работаете. У Вас же работает отличный парень, Игорь Беспальчук. Был где-то на его выступлении о системном подходе. Мне очень понравилось то, как он стройно и последовательно излагает свои мысли.
Не обижайтесь, но мне кажется, этот навык был бы Вам полезен :)
Хм. Я понимаю, Вашу логику но не совсем понимаю, как Вы предлагаете ее использовать для конкретных решений.
Вы пишите: " выясните, _почему_ ему нужны эти разнообразные выборки"
Ну ок, для нашей системы основные причины я знаю. Звонят внешние клиенты, которые задают вопросы, на которые должен ответить менеджер.
Что вы дальше будете делать с этой информацией?
Вы пишите: «В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения».
Ну ок. Приходит к вам задача — «дайте перечень наших самых первых 10 клиентов». А затем: «отберите договора выше 10 млн. за прошлый год»
Ок. Какие бы Вы сделали шаги для того, чтобы решить задачу ускорения времени доступа вашего пользователя к этим данным?
Так вроде с тем, что нужно идти от бизнес-задач никто и не спорит. В статье по пункту 10 я написал, как именно этот подход порождает хаос. Непонятно, как этот подход противоречит теме как этой так и предыдущей статей.
Знаете секретные знания, не держите в себе :)
А то теперь позиция изменилась на «Бизнес-требования, что бы это не значило, решат все проблемы.»
Ну да. А еще красота спасет мир.
Попробуйте конкретней. Например, если Вы утверждаете, что бизнес-требованиям в статье было уделено мало места, то поясните, какой процесс формирования бизнес-требований не был учтен в статье?
изучите, какие сценарии нужны пользователю, сделайте так, чтобы 80% из них были доступны в 1 клик
Тоже согласен.
Вот результат того, что я исследовал:
У пользователей ERP систем есть т.н. «длинный хвост» разнообразных выборок данных.
Т.е. есть 20% наиболее частых выборок (и они используются в 80% случаев по частоте). Эти выборки формолизованны и доступ к ним обеспечен (через отчеты или интерфейс) в 1-2 клика.
Но в 20% случаев пользователь использует очень разнообразные выборки, которые ему вряд ли понадобятся, например, в течении этого месяца повторно.
При этом, если пользователей 100 человек, то каждый день 3-5-и из них будут требоваться те самые редкие выборки.
Это исследование я проводил в компании с 3-мя системами и примерно 100 пользователями.
Таким образом, то решение, что Вы предложили действительно необходимо делать (и его собственно все делают, в том числе мы ). Далее я решал уже проблему «длинного хвоста».
Мой ход мыслей, который привел к совету рекомендаций 3-х свойств таблиц.
1. Разнообразных запросов слишком много. Все их формализовывать и выдавать в интерфейс а) слишком дорого б)слишком захламит интерфейс редкими операциями.
2. Чтобы получить нужные данные пользователи обращаются в ИТ и это работает. Что хорошо. Но удлиняет цепочку получения данных, что плохо.
3. Анализ этого потока показывает, что в большинстве случаев очень похожий источник данных в системе есть. Но не хватает его некой обработки. Задачи от пользователя так и приходят: возьмите все договоры и отберите по условию <условие>.
4. Если будет преложен пользователю инструмент, который остается удобным без навыков программирования но снимает 20-40% таких запросов, то это — хорошо.
5. Далее я формализовал, какие инструменты для этого нужны: доступ ко всем данным, фильтры, выгрузка в популярный формат. Но так, чтобы не ухудшать жизнь остальным пользователям.
Таким образом, мой ход рассуждения не противоречит Вашему. И обозначенной Вами подмены понятий, как мне кажется, я не сделал.
Сперва — решаем основные сценарии. Потом работаем над длинным хвостом.
Если говорить только о фильтрах, то в выступлении так и сказал — сделайте удобными основные сценарии, но для этого «длинного хвоста» сделайте более продвинутую кнопку фильтров.
Согласны ли Вы с моим ходом мысли?
И так, Вы написали «автор даже не осознает, что делает именно последний вариант». Видимо, имеется ввиду, что автор (я) не осознает причин, по которым захламляются учетные системы.
Я свою позицию по этому поводу написал. Судя по активности и рейтингу статьи, она была понятна большому количеству читателей. Попробуйте объяснить Вашу.
А то пока Ваша позиция звучит как «Я слишком умный для вас». Не кажется ли немного высокомерно? :)
Будьте корректны. То, что Вы не смотрели ролик, пенял лишь единожды, когда вы его еще видимо не посмотрели. Во второй раз предлагал и предлагаю обсуждение.
О своих пользователях я забочусь, обвинения беспочвенны, да и зачем они вообще?
Много советую не Вам а тем, кто пришел на форум, где я выступал. Да и нужно ли так нервничать из за советов? Выступление так построено, как 10 советов. Я же не принуждаю :)
Опять таки Вас не переубеждаю, а хочу выслушать и понять Ваши аргументы.
Я предложил тему обсуждения: «необходимость хороших таблиц для SelfService BI». Вы сказали, что выкинули бы данный совет. Я попросил аргументов (т.к. мои уже прозвучали).
Пока от меня идут предложения (и желание) обсуждать. От Вас — мелкие манипуляции, домыслы, обвинения. Давайте с этого места забудем об этом и переключимся на обсуждение.
И так: что в моих предположениях о таблицах Вам показалось лишним? Как бы Вы сами сформулировали главный первый совет?
Я думаю, мы бы могли интересно пообсуждать темы BI, если бы Вы захотели.
Например, интересная тема: Вы считаете, первый совет нужно выбросить, мне же он кажется самым полезным.
Почему он полезен — я пояснил, поясните, почему Вы считаете его лишним.
Но, конечно, будьте аккуратны в обсуждении:
… Вы по сути тут призываете дистанцироваться от реальных бизнес-сценариев и потребностей…
… Попробуйте, перечислите 5 самых частых сложных фильтров,… Не можете? Это потому…
По-моему в фильтрах я прямо привожу сценарий с документами. Поясняю причины, почему нужны такие фильтры. Если хотите пояснить свою точку зрения, попробуйте это сделать сами, не вкладывая от моего имени мысли, которых я не разделяю.
Если делать какой-нибудь учет упрощенки, то согласен. Тут можно посмотреть на Эльбу, как образец дружелюбности.
Но в корпоративном софте, где 800-2000 сущностей, срок жизни софта 3-5 лет, и нужно вложиться в бюджет… А что лучше?
(ну кроме нас :))))
Для решения этой проблемы мы ограничиваем то, что может менять пользователь. Например, не даем ему настраивать формы именно по этой причине.
Настройка колонок, или там, рабочего стола, таких вопросов вызывает. Но вообще да, каждый раз такой выбор — дилемма.
Кстати, есть типовое решение (плохое, но хороших мало :)) проблемы «переконфигурирования» — сброс системы в первоначальное состояние. Например, практикуется при сложной конфигурации настроек, когда пользователь может запутаться и перестать понимать, как все исправить.
В целом — согласен. Правда для меня 1С — более образец чем движок Force.com
Во истину, нет пророков в отечестве своем :)
Идею же штатных отчетов со сложной аналитикой частично берет на себя OLAP ну или там его развитие вроде One Click Report. Но, все же я не видел ни разу, чтобы такие отчеты смогли переложить на пользователей и это работало.
Типа:
1. Все крупными купюрами,
2. Разбить последнюю тысячу
3.…
Если три варианта закроют 90% выбора, то, считаю, ничего сложнее придумывать не стоит.
Бла-бла-бла. Сам так выступаю и рассказываю о «БОЛЬШОЙ КРАСНОЙ КНОПКЕ».
А вот в жизни приходится удобные таблицы и формы разрабатывать.
Вероятно, вы считаете своих оппонентов за идиотов?
Во-первых — касались Во вторых, учится то хорошо, что я и стараюсь делать. А вот не забыли ли Вы этот навык?
Если вы решите статью прочесть, то увидите что и внутри статьи речь идет преимущественно о анализе требований разными людьми на проекте и совокупностью их решений.
Вы написали, причину, которую я якобы не указал — это сбор бизнес-требований.
Однако большинство пунктов этой статьи посвящены сбору бизнес-требований. Я спросил, какой процесс не был учтен.
Вы пишете: сбор, выявление, преобразование в физическую модель.
ПРАВИЛЬНО ЛИ Я ПОНИМАЮ, ЧТО ЭТО НАЗВАНИЕ ПРОЦЕССОВ, КОТОРЫЕ Я НЕ УЧЕЛ В ПРИЧИНАХ?
В ПОЛОВИНА статьи посвящена сбору и выявлению требований. И вы все еще так и не сказали, как эти процессы влияют на захламление/очистку системы, кроме тех аспектов что я УЖЕ написал в статье.
Или я один из нас двоих слежу за нитью дискуссии? Если нет желания дискутировать, тогда стоило ли Вам ее продолжать?
Наверное, вы хороший консалтинговый специалист.
Наверное, закончим.
Игорю — привет :)
Не обижайтесь, но мне кажется, этот навык был бы Вам полезен :)
Вы пишите: " выясните, _почему_ ему нужны эти разнообразные выборки"
Ну ок, для нашей системы основные причины я знаю. Звонят внешние клиенты, которые задают вопросы, на которые должен ответить менеджер.
Что вы дальше будете делать с этой информацией?
Вы пишите: «В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения».
Ну ок. Приходит к вам задача — «дайте перечень наших самых первых 10 клиентов». А затем: «отберите договора выше 10 млн. за прошлый год»
Ок. Какие бы Вы сделали шаги для того, чтобы решить задачу ускорения времени доступа вашего пользователя к этим данным?
Знаете секретные знания, не держите в себе :)
А то теперь позиция изменилась на «Бизнес-требования, что бы это не значило, решат все проблемы.»
Ну да. А еще красота спасет мир.
Попробуйте конкретней. Например, если Вы утверждаете, что бизнес-требованиям в статье было уделено мало места, то поясните, какой процесс формирования бизнес-требований не был учтен в статье?
Согласен.
Тоже согласен.
Вот результат того, что я исследовал:
У пользователей ERP систем есть т.н. «длинный хвост» разнообразных выборок данных.
Т.е. есть 20% наиболее частых выборок (и они используются в 80% случаев по частоте). Эти выборки формолизованны и доступ к ним обеспечен (через отчеты или интерфейс) в 1-2 клика.
Но в 20% случаев пользователь использует очень разнообразные выборки, которые ему вряд ли понадобятся, например, в течении этого месяца повторно.
При этом, если пользователей 100 человек, то каждый день 3-5-и из них будут требоваться те самые редкие выборки.
Это исследование я проводил в компании с 3-мя системами и примерно 100 пользователями.
Таким образом, то решение, что Вы предложили действительно необходимо делать (и его собственно все делают, в том числе мы ). Далее я решал уже проблему «длинного хвоста».
Мой ход мыслей, который привел к совету рекомендаций 3-х свойств таблиц.
1. Разнообразных запросов слишком много. Все их формализовывать и выдавать в интерфейс а) слишком дорого б)слишком захламит интерфейс редкими операциями.
2. Чтобы получить нужные данные пользователи обращаются в ИТ и это работает. Что хорошо. Но удлиняет цепочку получения данных, что плохо.
3. Анализ этого потока показывает, что в большинстве случаев очень похожий источник данных в системе есть. Но не хватает его некой обработки. Задачи от пользователя так и приходят: возьмите все договоры и отберите по условию <условие>.
4. Если будет преложен пользователю инструмент, который остается удобным без навыков программирования но снимает 20-40% таких запросов, то это — хорошо.
5. Далее я формализовал, какие инструменты для этого нужны: доступ ко всем данным, фильтры, выгрузка в популярный формат. Но так, чтобы не ухудшать жизнь остальным пользователям.
Таким образом, мой ход рассуждения не противоречит Вашему. И обозначенной Вами подмены понятий, как мне кажется, я не сделал.
Сперва — решаем основные сценарии. Потом работаем над длинным хвостом.
Если говорить только о фильтрах, то в выступлении так и сказал — сделайте удобными основные сценарии, но для этого «длинного хвоста» сделайте более продвинутую кнопку фильтров.
Согласны ли Вы с моим ходом мысли?
Я свою позицию по этому поводу написал. Судя по активности и рейтингу статьи, она была понятна большому количеству читателей. Попробуйте объяснить Вашу.
А то пока Ваша позиция звучит как «Я слишком умный для вас». Не кажется ли немного высокомерно? :)
О своих пользователях я забочусь, обвинения беспочвенны, да и зачем они вообще?
Много советую не Вам а тем, кто пришел на форум, где я выступал. Да и нужно ли так нервничать из за советов? Выступление так построено, как 10 советов. Я же не принуждаю :)
Опять таки Вас не переубеждаю, а хочу выслушать и понять Ваши аргументы.
Я предложил тему обсуждения: «необходимость хороших таблиц для SelfService BI». Вы сказали, что выкинули бы данный совет. Я попросил аргументов (т.к. мои уже прозвучали).
Пока от меня идут предложения (и желание) обсуждать. От Вас — мелкие манипуляции, домыслы, обвинения. Давайте с этого места забудем об этом и переключимся на обсуждение.
И так: что в моих предположениях о таблицах Вам показалось лишним? Как бы Вы сами сформулировали главный первый совет?
Например, интересная тема: Вы считаете, первый совет нужно выбросить, мне же он кажется самым полезным.
Почему он полезен — я пояснил, поясните, почему Вы считаете его лишним.
Но, конечно, будьте аккуратны в обсуждении:
По-моему в фильтрах я прямо привожу сценарий с документами. Поясняю причины, почему нужны такие фильтры. Если хотите пояснить свою точку зрения, попробуйте это сделать сами, не вкладывая от моего имени мысли, которых я не разделяю.
Но в корпоративном софте, где 800-2000 сущностей, срок жизни софта 3-5 лет, и нужно вложиться в бюджет… А что лучше?
(ну кроме нас :))))
Настройка колонок, или там, рабочего стола, таких вопросов вызывает. Но вообще да, каждый раз такой выбор — дилемма.
Кстати, есть типовое решение (плохое, но хороших мало :)) проблемы «переконфигурирования» — сброс системы в первоначальное состояние. Например, практикуется при сложной конфигурации настроек, когда пользователь может запутаться и перестать понимать, как все исправить.
Во истину, нет пророков в отечестве своем :)
Идею же штатных отчетов со сложной аналитикой частично берет на себя OLAP ну или там его развитие вроде One Click Report. Но, все же я не видел ни разу, чтобы такие отчеты смогли переложить на пользователей и это работало.