Комментарии 124
Если говорить именно об интерфейсах и их удобстве, то их разработка — это отдельное искусство и большие затраты. Чего греха таить многие на этом экономят и получают YOUR COMPANY'S APP… Говорят программисту: «Добавь там одну кнопочку...» и так в цикле 100 раз.
>> перечень доработок, который будет ОПЛАЧЕН, если их разработать. И значит, он будет разработан!
Отсюда следствие: надо держать свою команду разработки на зарплате.
Свой Product Owner сто раз подумает и попытается обобщить функционал, нужный разным отделам, потому что IT-команде платят фиксированную ставку (не считая премии), а поток доработок просто нескончаем. Свой PO максимизирует пользу системы для предприятия, т.к. от этого зависит его положение в компании. Приходится в первую очередь разрабатывать самое важное, и не дублировать.
Внешний разработчик, у которого каждая фича стоит фиксированную цену, будет брать количеством копипасты, выбирая задачи попроще. Он максимизирует свою прибыль.
Отсюда следствие: надо держать свою команду разработки на зарплате.
Свой Product Owner сто раз подумает и попытается обобщить функционал, нужный разным отделам, потому что IT-команде платят фиксированную ставку (не считая премии), а поток доработок просто нескончаем. Свой PO максимизирует пользу системы для предприятия, т.к. от этого зависит его положение в компании. Приходится в первую очередь разрабатывать самое важное, и не дублировать.
Внешний разработчик, у которого каждая фича стоит фиксированную цену, будет брать количеством копипасты, выбирая задачи попроще. Он максимизирует свою прибыль.
Вы предполагаете или знаете успешные примеры? Своя команда разработчиков творит примерно такое же, как на последней картинке. При этом потеряла страх, так как только они знают где какой костыль и без них это все не взлетит.
Свой PO максимизирует пользу системы для предприятия, т.к. от этого зависит его положение в компании.
Не факт. Положение может зависеть от многого. В частности от степени замыкании процессов разработки и поддержки ИС предприятия на себя, именно на себя лично, а не на свою должность/роль.
Со своей командой разработчиков ещё хуже — если чужой команде вы выставляете CR, они озвучивают цену, вы согласовываете функциональность, а потом они уже разрабатывают, то своим разработчикам обычно звонят прямо из бухгалтерии и требуют срочно прикрутить кнопочку, потому что она позарез нужна для генерации какого-нибудь нового отчёта руководству.
Вот на этот вопрос я ещё не нашёл ответа.
Что лучше:
1. Пользователь понимает, что может существенно оптимизировать свои действия, бежит к местным программистам, капризничает и заставляет их писать кнопочку специально для него. Программисты срывают сроки разработки плановых фич.
2. Пользователю говорят: мы тебе купили систему за 20 млн, сиди и работай как она построена, за тебя уже 100500 человек подумало. В итоге пользователь либо говорит начальству, что такой отчёт в принципе невозможен в рамках существующей системы, либо сидит 3 дня и копипастит ячейки в excel-е. Разработчиков зато не дёргают, вливая новые сверхсрочные фичи в середине итерации.
Что лучше:
1. Пользователь понимает, что может существенно оптимизировать свои действия, бежит к местным программистам, капризничает и заставляет их писать кнопочку специально для него. Программисты срывают сроки разработки плановых фич.
2. Пользователю говорят: мы тебе купили систему за 20 млн, сиди и работай как она построена, за тебя уже 100500 человек подумало. В итоге пользователь либо говорит начальству, что такой отчёт в принципе невозможен в рамках существующей системы, либо сидит 3 дня и копипастит ячейки в excel-е. Разработчиков зато не дёргают, вливая новые сверхсрочные фичи в середине итерации.
Ну это смотря как команда разработки себя поставит внутри компании.
Такие поползновения нужно пресекать, и это возможно
Такие поползновения нужно пресекать, и это возможно
Это трудноосуществимо. Вот пара примеров:
1. Менеджер просит какую-то кнопку, чтобы сформировать отчёт директору. Если её не сделать, отчёт сорван, программисты виноваты. Позиция директора — вам же не сложно, помогите человеку.
2. Менеджер прибегает с фразой: а вы знаете, что завтра начинает действовать акция, код для её поддержки уже написан? Как, вы не читаете блог коммерческого отдела в корпоративном портале? Делайте срочно, а не то репутация компании пострадает, мы уже про эту акцию биллборды повесили везде.
1. Менеджер просит какую-то кнопку, чтобы сформировать отчёт директору. Если её не сделать, отчёт сорван, программисты виноваты. Позиция директора — вам же не сложно, помогите человеку.
2. Менеджер прибегает с фразой: а вы знаете, что завтра начинает действовать акция, код для её поддержки уже написан? Как, вы не читаете блог коммерческого отдела в корпоративном портале? Делайте срочно, а не то репутация компании пострадает, мы уже про эту акцию биллборды повесили везде.
Ой как знакомо, особенно п.2. Решали и решили эту проблему успешно, теперь менеджеры согласуют с разработчиками все новые акции как минимум за 2 недели. У разработчика есть право вето, то есть он может сказать, что реализовать данную акцию физически невозможно (ну точнее стоимость разработки будет выше, чем гипотетическая прибыль от её проведения).
Если бы всё так просто было…
По уму прежде чем проводить интеграцию с любой ЕРП-системой, нужно иметь построенную адекватную модель бизнес-процессов компании. Т.е. в компании должен быть человек, для которого компания прозрачна. И да, это утопия. Особенно учитывая, что адекватный бизнес гибко перестраивается, адаптируется к реалиям, поэтому невозможно создать одну модель раз и на всегда, она должна успевать отражать процессы в компании динамически. Это дважды утопия.
Давным-давно я был на форуме, проводившемся IDS Sheer. Эта компания как раз занимается ПО для бизнес-моделинга, поэтому все тематики выступлений были про бизнес-моделирование.
Очень понравилось выступление одного энергетика, Мужик был генеральным директором большой энергетической компании, но уровень его знаний в ИТ был не меньше начальника отдела, настолько хорошо было видно как он понимает не только проблемы бизнеса, но и как решать их с помощью ИТ. За 7 лет интенсивной работы они прописали около 30% бизнес-процессов. Не потому что занимались этим спустя рукава, не потому что у них был плохой инструмент (ARIS — это очень мощная (и очень дорогая) вещь), а потому что всё долго. Большинство бизнес-процессов в наших крупных компаниях не то, чтобы формализованы и рефактурированы, но они и не документированы никак. Орг структуры тащатся еще с советстких времен, основа для них — ведомственные документы времен Очакова и покоренья Крыма.
Данность ситуации как раз в том, что никто до конца не знает, что у них происходит. А ведь есть еще компании очень далекие от ИТ…
Очень понравилось выступление одного энергетика, Мужик был генеральным директором большой энергетической компании, но уровень его знаний в ИТ был не меньше начальника отдела, настолько хорошо было видно как он понимает не только проблемы бизнеса, но и как решать их с помощью ИТ. За 7 лет интенсивной работы они прописали около 30% бизнес-процессов. Не потому что занимались этим спустя рукава, не потому что у них был плохой инструмент (ARIS — это очень мощная (и очень дорогая) вещь), а потому что всё долго. Большинство бизнес-процессов в наших крупных компаниях не то, чтобы формализованы и рефактурированы, но они и не документированы никак. Орг структуры тащатся еще с советстких времен, основа для них — ведомственные документы времен Очакова и покоренья Крыма.
Данность ситуации как раз в том, что никто до конца не знает, что у них происходит. А ведь есть еще компании очень далекие от ИТ…
На последней картинке надо написать itunes.
На какой форме айтюнса вы такое увидели? Можно скрин?
Вcё-таки YOUR COMPANY'S APP разрабатывают исходя из требований реальных пользователей сидящих в соседнем кабинете, и нём обычно есть хоть какая-то внутренняя логика и непротиворечивость, в отличие от :)
Соглашусь, кстати, с этим. Обилие кнопок не означает, что там дерьмово всё написано. Возможно, наоборот, это результат эволюции, приведший к исключительно удобному результату.
Впрочем, как мне кажется, YOUR COMPANY'S APP означает, что это всего лишь разработка вашей компании, не факт, что вы сами этим приложением пользуетесь.
Впрочем, как мне кажется, YOUR COMPANY'S APP означает, что это всего лишь разработка вашей компании, не факт, что вы сами этим приложением пользуетесь.
Вставлю свои пять копеек, т.п. предназначение этой программы (iTunes) постоянно мозг мне выносит. Название говорит о том, что эта программа связана с музыкой, но она ещё выполняет синхронизацию и администрирование iPad/iPod/iPhone, в ней можно через встроенный App Store покупать книги и программы для iPhone/iPad (в то время, как программы для Mac OS X покупаются в отдельной программе App Store) и в ней встречаются такие загадочные для неискушённого пользователя названия как «Genius», «Подкасты», «iTunes U» и «iTunes Match».
На iPad всё ещё хуже — есть отдельная программа «Музыка», а iTunes является копией части программы App Store (притом в App Store можно покупать музыку, но не фильмы, а в iTunes можно покупать и музыку и фильмы). Так что для пользователей «экосистемы» Apple это дополнительный вынос мозга.
На iPad всё ещё хуже — есть отдельная программа «Музыка», а iTunes является копией части программы App Store (притом в App Store можно покупать музыку, но не фильмы, а в iTunes можно покупать и музыку и фильмы). Так что для пользователей «экосистемы» Apple это дополнительный вынос мозга.
Множество различных людей из различных отделов создают ПОТОК СОЗДАНИЯВидимо ПОТОК СОЗНАНИЯ.
По большей части, дело за проектировщиком/системным аналитиком, который часто видит свою задачу как «впихнуть все кнопки в интерфейс». А следовало бы перевести все формулировки клиента «добавьте кнопку, которая ...» в пожелания вида «нам нужно иметь возможность ...», объединить дубли и сделать вместо 10 кнопок всего 3. Но это, конечно, при условии, что клиент готов выслушивать предложения.
Это я все к тому, что не все так мрачно, и вменяемые ERP могут получаться, если обе стороны проявляют заинтересованность в результате. Кстати, в этом смысле лучший заказчик — фирма, уже имевшая дело с неудобным ПО и халтурным внедрением. Они обязательно найдут время на то, чтобы согласовать правки и вместе подумать, как сделать удобнее.
Это я все к тому, что не все так мрачно, и вменяемые ERP могут получаться, если обе стороны проявляют заинтересованность в результате. Кстати, в этом смысле лучший заказчик — фирма, уже имевшая дело с неудобным ПО и халтурным внедрением. Они обязательно найдут время на то, чтобы согласовать правки и вместе подумать, как сделать удобнее.
Фирма — большой коллектив и вовсе не факт, что его руководство будет заботится об удобстве рядовых исполнителей. Даже у гендира и главбуха могут быть разные требования. Угадайте, чьи будут реализованы прежде всего?
А это нормально. Гендиру нужна аналитическая справка по компании, из которой он в случае необходимости он может провалиться в нижестоящие цифры и посмотреть бюджеты/операции. Главбуху нужен баланс и отчетность, баланс, чтобы удостовериться, что учли все операции, а отчётность — чтобы было что показать ген.диру, и, внимание — сдача документов в налоговую, потому что налоговая вопросы задает в первую очередь главбуху, а потом уже генеральному.
> Кстати, в этом смысле лучший заказчик — фирма, уже имевшая дело с неудобным ПО и халтурным внедрением.
> Они обязательно найдут время на то, чтобы согласовать правки и вместе подумать, как сделать удобнее.
В реальной жизни героев внедрения за успехи ставят на другие должности, перебрасывают с поддержки внедренного на внедрение других продуктов, они сами уходят с повышением на внедрения в другие конторы.
Продолжительность внедрения — обычно год, срок жизни внедренного продукта до замены — лет пять, среднее время работы специалиста на одном месте — менее трех лет.
И как итог — в следующем внедрении ходивших по граблям в предыдущем практически не оказывается.
> Они обязательно найдут время на то, чтобы согласовать правки и вместе подумать, как сделать удобнее.
В реальной жизни героев внедрения за успехи ставят на другие должности, перебрасывают с поддержки внедренного на внедрение других продуктов, они сами уходят с повышением на внедрения в другие конторы.
Продолжительность внедрения — обычно год, срок жизни внедренного продукта до замены — лет пять, среднее время работы специалиста на одном месте — менее трех лет.
И как итог — в следующем внедрении ходивших по граблям в предыдущем практически не оказывается.
Я вот никакого отношения к написанию ERP систем не имею, но мне интересно.
Почему нельзя нанять компанию/человека(из мира IT) который сядет на место каждого человека который будет пользоваться системой, соберет список вещей которые ему нужны, а потом создаст по всему этому согласованное ТЗ? Причем все это в виде отдельного проекта, целью которого понять что нужно сделать, или как можно скорректировать бизнес процессы. Задача довольно нетривиальная, но выполнимая, при условии что люди которые занимаются этим проектом добросовестные и при условии, что им правильно поставили задачу.
Просто мне кажется, что проблема в самом подходе «собрать тендер из 10 фирм и выбрать одну», потому что забота каждой такой фирмы в том, что бы продать свой продукт, а не в том, что бы улучшить чьи-то бизнес процессы
Почему нельзя нанять компанию/человека(из мира IT) который сядет на место каждого человека который будет пользоваться системой, соберет список вещей которые ему нужны, а потом создаст по всему этому согласованное ТЗ? Причем все это в виде отдельного проекта, целью которого понять что нужно сделать, или как можно скорректировать бизнес процессы. Задача довольно нетривиальная, но выполнимая, при условии что люди которые занимаются этим проектом добросовестные и при условии, что им правильно поставили задачу.
Просто мне кажется, что проблема в самом подходе «собрать тендер из 10 фирм и выбрать одну», потому что забота каждой такой фирмы в том, что бы продать свой продукт, а не в том, что бы улучшить чьи-то бизнес процессы
Как человек из мира ERP, имею сказать :)
У нас в компании аналитик обследует все бизнес процессы компании, после чего оптимизирует их и пишет ТЗ. Так вот, когда заказчик видит это ТЗ, он делает огромные глаза и говорит, что у них так не работают, а надо вот так. И после этих слов выдается поток бреда, который приходится записывать и реализовывать, иначе не подпишут ТЗ, а потом и акт.
На все объяснения, что подобный бред делать нельзя и не надо, заказчик плюет. А после опытной эксплуатации и полугодового использования, заказчик заказывает второй проект, в рамках которого система допиливается до первого предложенного аналитиком варианта.
У нас в компании аналитик обследует все бизнес процессы компании, после чего оптимизирует их и пишет ТЗ. Так вот, когда заказчик видит это ТЗ, он делает огромные глаза и говорит, что у них так не работают, а надо вот так. И после этих слов выдается поток бреда, который приходится записывать и реализовывать, иначе не подпишут ТЗ, а потом и акт.
На все объяснения, что подобный бред делать нельзя и не надо, заказчик плюет. А после опытной эксплуатации и полугодового использования, заказчик заказывает второй проект, в рамках которого система допиливается до первого предложенного аналитиком варианта.
Такой человек обычно есть в тех самых компаниях, которые делают такие приложения. Называется он бизнес-аналитиком.
Однажды я участвовал в подобном проекте на основной роли «разработчик» и по совместительству «помощник аналитика». Столкнулись с тем, что рядовые исполнители, будущие пользователи системы, ничего не хотят менять, они не заинтересованы в оптимизации бизнес-процессов. Как минимум, они не хотят учиться новому, боятся процесса внедрения, как максимум оптимизация может грозить им сокращением. Например, сидит отдельный человек на агрегировании данных типа заявок или прогнозов, чтобы не получить втык от начальства. В первом приближении работу этого человека простой скрипт может выполнять. Потом узнаешь, что есть нюансы, например, что некоторые первичные документы этот человек отправляет на доработку по каким-то критериям, а критерии эти раскрывать не хочет, понимая что эти критерии и есть его основная ценность для предприятия. А может хочет, но формализовать их не в состоянии — это другая проблема.
В статье об этом уже написано. В кратце — все стороны (отделы и конкретные люди), участвующие в создании, внедрении и сопровождении софта имеют разные цели. Поэтому софт получается таким, каким получается.
Немного провокационный вопрос, но тем не менее:
что плохого в том, что ERP выглядят так как вы нарисовали?
что плохого в том, что ERP выглядят так как вы нарисовали?
В том, что ей не удобно пользоваться и потому зачастую бухи продолжают считать все в экселях, занося в отчеты готовую цифру.
Как правило, огромное количество этих кнопок не несет смысловой нагрузки для конкретного АРМа, и находится тут просто по тому, что где-то в другом месте нужна сортировка/доп-инфа/фишка, а в этой программе один интерфейс на всех. И добавить на него одну кнопку на этапе внедрения менее затратно, чем клепать отдельный интерфейс. Вот и получается, если у вас раз в году будет контрагент с двумя факсами, вы все время будете видеть на экране поле "факс2" между "факс1" и "почта". И будете попадать на него при табуляции. И это еще не плохой вариант, поскольку оно может оказаться обязательным для заполнения =)
Как правило, огромное количество этих кнопок не несет смысловой нагрузки для конкретного АРМа, и находится тут просто по тому, что где-то в другом месте нужна сортировка/доп-инфа/фишка, а в этой программе один интерфейс на всех. И добавить на него одну кнопку на этапе внедрения менее затратно, чем клепать отдельный интерфейс. Вот и получается, если у вас раз в году будет контрагент с двумя факсами, вы все время будете видеть на экране поле "факс2" между "факс1" и "почта". И будете попадать на него при табуляции. И это еще не плохой вариант, поскольку оно может оказаться обязательным для заполнения =)
тут, как не удивительно, палка о многих концах.
удобство — это ооочень субъективный параметр, особенно если говорить не о первом использовании программы, а о некотором периоде.
пример месячной давности. Управляющая компания, в которой есть 2 женщины забивающие наряды о произведенных работах в комп.
текущая версия АРМ написана на фоксе в те времена, когда дед моего прадеда не родился. вообразите самый ужасный и неинтуитивный интерфейс и вы ошибетесь раза в два от реальности.
при этом — заполнения наряда 7 — 11 секунд. в наряде примерно 9 полей. женщины привыкли и набирают наряд вслепую, не ошибаясь. просто стучат по хоткеям. и попробовали показать веб куй, с красявостами, интуитивностями и эгономичностями — время заполнения наряда 40 — 60 секунд. тутже показывали виндовый гуй тоже «интуитывный» — время заполнения 22-25 секунд (в обоих случая вводили разработчики продуктов, у тетенек разумеется результаты были хуже). реакция женщин на нововведения предсказуема, правда?
аналогичный пример: один из процессов на заводе, форма портянка на 263 поля, как это выглядит лучше даже не начинать обсуждать, но каждый из участников процесса знает где ему надо нажать и какие варианты ответа системы могут быть. ( у каждого из участников от 5 до 20 «его» рабочих полей)
это я к чему — в большинстве случаев людям работающим с ерп важно как быстро происходит ввод их данных, а не то как выглядит в целом гуй. у них есть масса других дел кроме этих ваших компьютеров.
удобство — это ооочень субъективный параметр, особенно если говорить не о первом использовании программы, а о некотором периоде.
пример месячной давности. Управляющая компания, в которой есть 2 женщины забивающие наряды о произведенных работах в комп.
текущая версия АРМ написана на фоксе в те времена, когда дед моего прадеда не родился. вообразите самый ужасный и неинтуитивный интерфейс и вы ошибетесь раза в два от реальности.
при этом — заполнения наряда 7 — 11 секунд. в наряде примерно 9 полей. женщины привыкли и набирают наряд вслепую, не ошибаясь. просто стучат по хоткеям. и попробовали показать веб куй, с красявостами, интуитивностями и эгономичностями — время заполнения наряда 40 — 60 секунд. тутже показывали виндовый гуй тоже «интуитывный» — время заполнения 22-25 секунд (в обоих случая вводили разработчики продуктов, у тетенек разумеется результаты были хуже). реакция женщин на нововведения предсказуема, правда?
аналогичный пример: один из процессов на заводе, форма портянка на 263 поля, как это выглядит лучше даже не начинать обсуждать, но каждый из участников процесса знает где ему надо нажать и какие варианты ответа системы могут быть. ( у каждого из участников от 5 до 20 «его» рабочих полей)
это я к чему — в большинстве случаев людям работающим с ерп важно как быстро происходит ввод их данных, а не то как выглядит в целом гуй. у них есть масса других дел кроме этих ваших компьютеров.
Совершенно точно. Именно так это и есть. Нежелание пользователей обучаться новому часто обусловлено не только и не столько их ленью, сколько тем, что налаженный и привычный (пусть не самый удобный и красивый) процесс начинает сбоить, если ввести изменения в интерфейс программы, существенно этот процесс (ввода, обработки) меняющие. Конечно, раньше или позже они привыкнут к новому интерфейсу, и скорость обработки возрастёт примерно до прежнего уровня, но может быть ниже, если новый интерфейс оказался хуже продуман, а может и выше, если продумали лучше и сумели грамотно оптимизировать.
Но работа-то идёт сейчас. А сейчас, из-за нового интерфейса, она идёт намного медленнее, чем раньше. Для привыкания требуется время. Или обучение на специально выделенном учебном оборудовании в специально выделенное из рабочего время. А это далеко не всегда возможно. Вот как-то так.
Но работа-то идёт сейчас. А сейчас, из-за нового интерфейса, она идёт намного медленнее, чем раньше. Для привыкания требуется время. Или обучение на специально выделенном учебном оборудовании в специально выделенное из рабочего время. А это далеко не всегда возможно. Вот как-то так.
куй, с красявостами, интуитивностями и эгономичностями
Красявости и интуитивность к эргономичности не относится по большому счёту. Решили создать новый UI — посчитайте, чтобы для типичных действий требовалось не больше, как минимум, нажатий клавиш/перемещений и кликов, чем в «досовской» версии. Сумели это число сократить — реальный повод для внедрения. Не сумели хотя бы не уменьшить — очень большой минус к необходимости внедрения, если система основана на агрегации первичных документов. и их ввод занимает большую часть работы с документами.
Красявости и интуитивность не должны мешать основному процессу (после обучения операторов). Они должны помогать обучению, а не замедлять основной процесс. Естественно, если для ввода поля фиксированной длины (типа почтового индекса) вы забыли сделать автопереход на следующее поле по его заполнению, или вместо короткого индекса типа ru или us сделали дропдаун список с неиндексными пунктами (и без автоперехода после выбора), и всё это было в «досовской» версии, то об эргономичности говорить нечего.
Наблюдал пример подобного внедрения.
Был терминальный клиент, где всё делалось реально хоткеями — там можно было быстро перемещаться по разделам и вбивать документы на одной дополнительной клавиатуре — вы не представляете, как это удобно и быстро. Появился «богатый gui» с убогой архитектурой навигации без всяких хоткеев — производительность на нём по определению не может быть высокой.
Так что все эти красивости — идут по известном на Руси адресу до тех пор, пока не будет организована эффективная система навигации и ввода. Мышиная возня таковой не является по определению, если мы не говорим о пространственно позиционируемых объектах вроде чертежа.
Был терминальный клиент, где всё делалось реально хоткеями — там можно было быстро перемещаться по разделам и вбивать документы на одной дополнительной клавиатуре — вы не представляете, как это удобно и быстро. Появился «богатый gui» с убогой архитектурой навигации без всяких хоткеев — производительность на нём по определению не может быть высокой.
Так что все эти красивости — идут по известном на Руси адресу до тех пор, пока не будет организована эффективная система навигации и ввода. Мышиная возня таковой не является по определению, если мы не говорим о пространственно позиционируемых объектах вроде чертежа.
Не дописал.
В подавляющем большинстве случаев разработчики понятия не имеют как поставлен процесс работы с ерп у заказчика, именно поэтому внедрение ерп стоит дороже чем лицензия на него.
разработчики редко бывают в поле и смотрят работу пользователей с их продуктом, за этим смотрят аналитики, а у них как правило задача «выполнить пункт требованих номер Х». Поэтому у разработчиков, как правило, нет никаких объективных данных о том как улучшать гуй продукта.
Даже если задаться целью сделать идеальный гуй, то с учетом того, что в каждой фирме свой процесс придется многое переделывать под каждого заказчика, стоимость возрастет весьма заметно.
Ради интереса, рекомендую почитать мемуары советских конструкторов, которые поднимали промышленность в 30х. там очень много пишется про то как мы запроектировали вот так, а потом случайно увидели как люди в реальности этим пользуются — поняли какие мы идиоты. От проектирования гуев далеко, конечно, но проблемы в целом теже.
В подавляющем большинстве случаев разработчики понятия не имеют как поставлен процесс работы с ерп у заказчика, именно поэтому внедрение ерп стоит дороже чем лицензия на него.
разработчики редко бывают в поле и смотрят работу пользователей с их продуктом, за этим смотрят аналитики, а у них как правило задача «выполнить пункт требованих номер Х». Поэтому у разработчиков, как правило, нет никаких объективных данных о том как улучшать гуй продукта.
Даже если задаться целью сделать идеальный гуй, то с учетом того, что в каждой фирме свой процесс придется многое переделывать под каждого заказчика, стоимость возрастет весьма заметно.
Ради интереса, рекомендую почитать мемуары советских конструкторов, которые поднимали промышленность в 30х. там очень много пишется про то как мы запроектировали вот так, а потом случайно увидели как люди в реальности этим пользуются — поняли какие мы идиоты. От проектирования гуев далеко, конечно, но проблемы в целом теже.
Настройка индивидуальных или ролевых АРМ разве не выход? Или адаптируемый под права текущего пользователя UI? В общем у каждого только те кнопки, которые он имеет право нажимать, а которые не имеет ему и показывать незачем, все равно задизэйблены (вы же при внедрении четко устанавливаете права, только необходимые?). В том же 1C: Предприятие создать интерфейс для конкретного пользователя и отключить ненужные возможности дело нескольких минут, емнип. Может ещё несколько минут оставшиеся перегруппировать. Или я чего-то не понимаю?
Вы сами отвечаете на свой же вопрос:
это
и это
ответ явный. Увеличивайте количество специализированных экранов для специфических задач и не засоряйте ненужными кнопками каждый экран. Для разных типов работ пользователям нужно будет входить в разные экраны.
По крайней мере моя система так решает этот вопрос.
это
сманите его себе на работу, дайте должность “аналитика информационной системы”, и дайте ему только одно задание — “уменьшать количество кнопок”.
и это
Может быть именно Вы будете тем самым человеком, кто сможет решить эту проблему.
ответ явный. Увеличивайте количество специализированных экранов для специфических задач и не засоряйте ненужными кнопками каждый экран. Для разных типов работ пользователям нужно будет входить в разные экраны.
По крайней мере моя система так решает этот вопрос.
Когда ваша система будет внедрена в 4 -5 компаниях, путь даже одного бизнес направления или переживет слияние вашей компании с какой-нибудь еще вот тогда можно будет проанализировать полученный опыт и решить как система справляется.
Вам не нравится подход? Уже были изменения подобного рода, для различных задач создаются отдельные экраны управления и пользователи получают в них специфически то что им надо.
В рамках одной небольшой компании это вполне может работать. когда появится много магазинов, разные страны, разные комплаенсы, и много еще чего — вот тогда врядли.
почемуто многие воспринимают ерп — как бухгалтерия + склад. а это дай бог чтобы 10%.
почемуто многие воспринимают ерп — как бухгалтерия + склад. а это дай бог чтобы 10%.
Еще раз, вам не нравится подход? Часто одни и теже данные используются для различной функциональности в разных экранах управления, не мешая другим работать. Что именно вам не нравится в подходе использования отдельных экранов управления для решения отдельных задач (и количество функциональности не имеет значения и ограничения с этим подходом принципиально).
пример: работа с таможенными декларациями. примените там ваш подход.
Ваш пример не отвечает на вопрос и ничего не меняет. Каким образом добавление новой функции должно отразиться на всей существующей функциональности системы, особенно частей вообще не касающихся тех же деклараций? Добавление новой функциональности может изменить какие-то существующие элементы контроля, но это означает что персонал, который использует уже существующую функциональность в любом случае должен начать принимать во внимание новую функцию.
Возможно у вас вопрос более широкий — какого типа изменение требует введение новых экранов для контроля и какого типа изменение не требует их? Добавление новой информации к любому экрану должно быть оправдано так, чтобы существующая функциональность оставалась, а новая не мешала тем кто уже работает.
Для работы с новым типом документа (декларация), нужны новые экраны. От поиска до создания / редактирования / выполнения. Я совершенно не вижу как этот пример меняет структуру подхода к разработке всей системы.
Возможно у вас вопрос более широкий — какого типа изменение требует введение новых экранов для контроля и какого типа изменение не требует их? Добавление новой информации к любому экрану должно быть оправдано так, чтобы существующая функциональность оставалась, а новая не мешала тем кто уже работает.
Для работы с новым типом документа (декларация), нужны новые экраны. От поиска до создания / редактирования / выполнения. Я совершенно не вижу как этот пример меняет структуру подхода к разработке всей системы.
Забавно что вы судите о чем-то, не имея представления о предметной области. в результате все выдвинутые вам предположения не верны.
декларация это несколько объемных документов с кучей полей. всем участникам процесса нужно видеть все эти поля, даже при том, что редактировать они могут только некоторые. поэтому ваш подход показа пользователям разных экранов с «их» полями — не вариант.
новых типов деклараций не существует и новых экранов не надо. Повторюсь, вы «совершенно не видите» неприменимость вашего подхода, потому что не знаете предметной области. На мой взгляд это опрометчиво.
декларация это несколько объемных документов с кучей полей. всем участникам процесса нужно видеть все эти поля, даже при том, что редактировать они могут только некоторые. поэтому ваш подход показа пользователям разных экранов с «их» полями — не вариант.
новых типов деклараций не существует и новых экранов не надо. Повторюсь, вы «совершенно не видите» неприменимость вашего подхода, потому что не знаете предметной области. На мой взгляд это опрометчиво.
Еще раз, вам не нравится подход? Где и в каком конкретном комментарии я написал что нельзя изменять какой-то конкретных экран, если в нем абсолютно требуется какая-то функциональность? Если функция принадлежит в экране управления, то она должна там присутствовать и ваш пример, как и любой другой пример совершенно вписывается в рамки подхода.
Любой экран управления имеет своего пользователя, это ответ на вопрос что должно быть на экране и какие функции в нем должны присутствовать.
Любой метод контроля нужно делать настолько простым насколько это возможно, но не проще.
Любой экран управления имеет своего пользователя, это ответ на вопрос что должно быть на экране и какие функции в нем должны присутствовать.
Любой метод контроля нужно делать настолько простым насколько это возможно, но не проще.
Еще раз: ваш подход применим в ограниченном количестве случаев. Если вы будете смешивать разные подходы к проектированию гуя в одном приложении, то, вероятнее всего, у вас быстро начнется каша.
Любой экран управления как правило имеет несколько групп пользователей, которые смотрят все данные, но выполняют ( каждая группа) свои операции.
Афоризмы это отличная штука, правда на любой из них всегда можно найти такой же яркий, но с противоположным смыслом, например:
для любой проблемы существует красивое, элегантрое, простое и неверное решение
Любой экран управления как правило имеет несколько групп пользователей, которые смотрят все данные, но выполняют ( каждая группа) свои операции.
Афоризмы это отличная штука, правда на любой из них всегда можно найти такой же яркий, но с противоположным смыслом, например:
для любой проблемы существует красивое, элегантрое, простое и неверное решение
Не вижу для чего нужно 'смешивать' разные подходы проектирования в одном приложении, но если под этим вы подразумеваете возможность добавления какого-то например текстового поля или клавиши или еще какого-то элемента управления к уже существующему экрану, вместо того, чтобы всегда жестко дописывать новый экран, тогда вы меня совсем не поняли.
Еще раз: любой пользователь имеет свой набор функциональности и данных, с которым ему нужно работать. Любой пользовательский экран должен соответствовать какой то функции. Если в нем не хватает какого-то элемента, который требуется для нормального выполнения этой функции, то элемент нужно добавить.
Мой подход не какой-то уникальный, я говорю о разделении системы на логические сегменты, разделение прав пользователей к доступу к данным и определению функций для любого экрана или секции таким образом, чтобы этот экран соответствовал своей функции.
Доступ и функциональность для директора магазина отличается от доступа и функциональности бухгалтера или категорийного менеджера или отдела кадров или поставщика или владельца компании и т.д. Для них существуют отделные секции в интерфейсе, различные экраны сгруппированные таким образом, чтобы можно было разделять работу людей по их функции в компании по меньшей мере.
Я не вижу о чем вы со мной спорите, если вы только не проповедуете что всем пользователям системы нужен доступ ко всем данным и ко всем функциям и при чем в одном экране управления.
Еще раз: любой пользователь имеет свой набор функциональности и данных, с которым ему нужно работать. Любой пользовательский экран должен соответствовать какой то функции. Если в нем не хватает какого-то элемента, который требуется для нормального выполнения этой функции, то элемент нужно добавить.
Мой подход не какой-то уникальный, я говорю о разделении системы на логические сегменты, разделение прав пользователей к доступу к данным и определению функций для любого экрана или секции таким образом, чтобы этот экран соответствовал своей функции.
Доступ и функциональность для директора магазина отличается от доступа и функциональности бухгалтера или категорийного менеджера или отдела кадров или поставщика или владельца компании и т.д. Для них существуют отделные секции в интерфейсе, различные экраны сгруппированные таким образом, чтобы можно было разделять работу людей по их функции в компании по меньшей мере.
Я не вижу о чем вы со мной спорите, если вы только не проповедуете что всем пользователям системы нужен доступ ко всем данным и ко всем функциям и при чем в одном экране управления.
Директор и бухгалтер конечно имеют разные и не пересекающиеся функции. а что делать если у вас в бухгалтерии 50 человек и все они колотят платежки по своим участкам. форму плтежки тоже раной показывать? там ведь в зависимости от назначения платежа разные поля заполняются
50 бухгалтеров? У вас серьезные компании в уме, как я вижу. Но не важно, даже там где используется моя система есть несколько бухгалтеров они отвечают за разные данные (отдельные фирмы) и они видят данные по фирмам, которы касаются их конкретно. И даже внутри экранов (окон) есть различные роли, то есть то, что на экране соответствует своей функции. Конечно может быть что в какой-то ситуации на экране есть поле ввода данных например, которое не заполняется каждый раз для каждого случая.
Пример: некоторые поставщики могут не присылать счет фактуры, а некоторые присылают. То есть поле данных для счета фактуры может быть заполнено или нет (требование такое, что при отсутствии счета фактуры туда автоматом копировался номер накладной). Но это не меняет общего подхода, о котором я говорю.
Никто не говорит что экран должен всегда заполняться данными например на 100%, это не имеет смысла. Некоторые пользователи заведут свой телефон, а некоторые email адрес, а некоторые оба. Но от этого смысл функциональности не меняется.
Пример: некоторые поставщики могут не присылать счет фактуры, а некоторые присылают. То есть поле данных для счета фактуры может быть заполнено или нет (требование такое, что при отсутствии счета фактуры туда автоматом копировался номер накладной). Но это не меняет общего подхода, о котором я говорю.
Никто не говорит что экран должен всегда заполняться данными например на 100%, это не имеет смысла. Некоторые пользователи заведут свой телефон, а некоторые email адрес, а некоторые оба. Но от этого смысл функциональности не меняется.
50 бухгалтеров это конечно очень много, но это просто иллюстрация из понятной вам предметной области.
гораздо интереснее когда десятки начальников цехов, пара сотен мастеров, пара тысяч специалистов, сотни поставщиков, десятки тысяч единиц номенклатуры и стандартизованные формы ескд. ( средней руки заводик в общем).
в общем в области ерп за пределами розничной торговли вам будет ждать масса открытий.
гораздо интереснее когда десятки начальников цехов, пара сотен мастеров, пара тысяч специалистов, сотни поставщиков, десятки тысяч единиц номенклатуры и стандартизованные формы ескд. ( средней руки заводик в общем).
в общем в области ерп за пределами розничной торговли вам будет ждать масса открытий.
>>Директор и бухгалтер конечно имеют разные и не пересекающиеся функции. а что делать если у вас в бухгалтерии 50 человек и все они колотят платежки по своим участкам. форму плтежки тоже раной показывать?
Да. В типовых 1С в зависимости от операции в платежках показываются разные формы ввода. Не вижу в этом ничего удивительного
>>гораздо интереснее когда десятки начальников цехов, пара сотен мастеров, пара тысяч специалистов, сотни поставщиков, десятки тысяч единиц номенклатуры и стандартизованные формы ескд. ( средней руки заводик в общем).
Что изменится в подходе от количества человек? Ну будет интерфейс для специалистов, интерфейс для мастеров и интерфейс для начальников цехов (и еще десяток разных). Да количество работы по внедрению увеличится. Но тут и Вангой быть не нужно, чтобы понимать, что стоимость внедрения на крупном предприятии в любом случае будет намного выше, чем в чебуречной
Да. В типовых 1С в зависимости от операции в платежках показываются разные формы ввода. Не вижу в этом ничего удивительного
>>гораздо интереснее когда десятки начальников цехов, пара сотен мастеров, пара тысяч специалистов, сотни поставщиков, десятки тысяч единиц номенклатуры и стандартизованные формы ескд. ( средней руки заводик в общем).
Что изменится в подходе от количества человек? Ну будет интерфейс для специалистов, интерфейс для мастеров и интерфейс для начальников цехов (и еще десяток разных). Да количество работы по внедрению увеличится. Но тут и Вангой быть не нужно, чтобы понимать, что стоимость внедрения на крупном предприятии в любом случае будет намного выше, чем в чебуречной
в 7.7 и 8.0 форма платежки одна на все случае. если мы говорим о системе из коробки.
термин ескд говорит о чем нибудь? число участников обычно выливается в число ролей и сложность процессов. роли и процессы выливаются в сложный гуй. упрощать этот гуй без детального знания процессов заказчика и наличия ванги для определения как они (процессы) изменятся в будущем — достаточно бессмысленный и дорогостоящий процесс.
Возьмите дизайн гайды сапа или сейлфорса — там не самый глупые люди работают, очень интересно про дизайн гуев пишут.
Что изменится в подходе от количества человек? Ну будет интерфейс для специалистов, интерфейс для мастеров и интерфейс для начальников цехов (и еще десяток разных).
термин ескд говорит о чем нибудь? число участников обычно выливается в число ролей и сложность процессов. роли и процессы выливаются в сложный гуй. упрощать этот гуй без детального знания процессов заказчика и наличия ванги для определения как они (процессы) изменятся в будущем — достаточно бессмысленный и дорогостоящий процесс.
Возьмите дизайн гайды сапа или сейлфорса — там не самый глупые люди работают, очень интересно про дизайн гуев пишут.
>>в 7.7 и 8.0 форма платежки одна на все случае. если мы говорим о системе из коробки.
Примерно вот так выглядит документ платежное поручение исходящее в типовой УПП. За не имением под рукой УПП нарезал скриншотов из документа списание с расчетного счета из типовой бухгалтерии предприятия.
s55.radikal.ru/i148/1303/bc/df610ed676c4.png
s48.radikal.ru/i121/1303/0a/3cc48aeca841.png
s55.radikal.ru/i149/1303/09/4d9ee105990d.png
s52.radikal.ru/i137/1303/d1/d3c8a53bf673.png
s51.radikal.ru/i133/1303/f5/8718f9981a2d.png
s005.radikal.ru/i212/1303/38/35183581339b.png
i056.radikal.ru/1303/42/1f1b02f8e997.png
s018.radikal.ru/i503/1303/fa/92519a3e6ca2.png
>>термин ескд говорит о чем нибудь?
Слышал что-то. Только причем тут ERP и конструкторская документация?
>>Возьмите дизайн гайды сапа или сейлфорса — там не самый глупые люди работают, очень интересно про дизайн гуев пишут.
Сайлфорс не смотрел. А вот у сапа довольно блевотный интерфейс, я бы с них пример не брал. Посмотрите лучше в сторону интерфейсов обычного приложения и подсистем управляемого приложения в 1С
Примерно вот так выглядит документ платежное поручение исходящее в типовой УПП. За не имением под рукой УПП нарезал скриншотов из документа списание с расчетного счета из типовой бухгалтерии предприятия.
s55.radikal.ru/i148/1303/bc/df610ed676c4.png
s48.radikal.ru/i121/1303/0a/3cc48aeca841.png
s55.radikal.ru/i149/1303/09/4d9ee105990d.png
s52.radikal.ru/i137/1303/d1/d3c8a53bf673.png
s51.radikal.ru/i133/1303/f5/8718f9981a2d.png
s005.radikal.ru/i212/1303/38/35183581339b.png
i056.radikal.ru/1303/42/1f1b02f8e997.png
s018.radikal.ru/i503/1303/fa/92519a3e6ca2.png
>>термин ескд говорит о чем нибудь?
Слышал что-то. Только причем тут ERP и конструкторская документация?
>>Возьмите дизайн гайды сапа или сейлфорса — там не самый глупые люди работают, очень интересно про дизайн гуев пишут.
Сайлфорс не смотрел. А вот у сапа довольно блевотный интерфейс, я бы с них пример не брал. Посмотрите лучше в сторону интерфейсов обычного приложения и подсистем управляемого приложения в 1С
Интересно что вы решили что знаете о моей 'предметной области'.
В любом случае, в сети магазинов где на данный момент моя система используется работает около 200 людей, 15 челове в офисе и около 40 других людей по сети работают непосредственно в системе. Более сотни поставщиков (90 из них пользуются системой). Больше 46,000 наименований уникальных товаров и пр.
И я хочу заметить, что не вижу с вашей стороны ни одного возражения, которое действительно бы имело отношение к обсуждению подхода, о котором я говорю.
У любого 'экрана' или 'окна' есть определенная функциональность и если требуется добавить какой-то элемент контроля, необходимый для выполнения функции пользователя, то элемент должен быть добавлен. Если же требуется добавить новый тип функциональности, который может работать с теми-же данными, что и в предыдущем экране, но в тоже время именно функция пользователя отличается, то нужно добавлять другой экран. Это позволяет разделять функции на роли, это позволяет иметь специализированный подход к отображению и контролю данных.
В любом случае, в сети магазинов где на данный момент моя система используется работает около 200 людей, 15 челове в офисе и около 40 других людей по сети работают непосредственно в системе. Более сотни поставщиков (90 из них пользуются системой). Больше 46,000 наименований уникальных товаров и пр.
И я хочу заметить, что не вижу с вашей стороны ни одного возражения, которое действительно бы имело отношение к обсуждению подхода, о котором я говорю.
У любого 'экрана' или 'окна' есть определенная функциональность и если требуется добавить какой-то элемент контроля, необходимый для выполнения функции пользователя, то элемент должен быть добавлен. Если же требуется добавить новый тип функциональности, который может работать с теми-же данными, что и в предыдущем экране, но в тоже время именно функция пользователя отличается, то нужно добавлять другой экран. Это позволяет разделять функции на роли, это позволяет иметь специализированный подход к отображению и контролю данных.
Предположил, что ваша область описана на странице вашего продукта.
Почему я должен возражать против вашего подхода? я лишь говорю что в многих случаях он не работает.
то есть если изложить краткую версию дискуссии:
Вы: для решения проблемы со сложным гуем в ерп давайте показывать только те данные, которые нужны сейчас пользователю. в итоге интерфейс станет проще поскольку на нем будет меньше контролов.
Я: не вопрос, вот форма в ней почти 70 полей ( я про декларацию) их все надо показывать, поскольку только в сумме они определяют следующее действие пользователя. ваш подход не сработает. как быть дальше?
на основании опыта предположу что таких ситуаций сильно больше 50%. таким образом предполагаю, что с помощью вашего подхода проблему в целом не решить.
+ скриншоты вашей системы подтверждают ( особенно если предположить, что на них показаны только нужные данные) — интерфейс не получается простым.
Почему я должен возражать против вашего подхода? я лишь говорю что в многих случаях он не работает.
то есть если изложить краткую версию дискуссии:
Вы: для решения проблемы со сложным гуем в ерп давайте показывать только те данные, которые нужны сейчас пользователю. в итоге интерфейс станет проще поскольку на нем будет меньше контролов.
Я: не вопрос, вот форма в ней почти 70 полей ( я про декларацию) их все надо показывать, поскольку только в сумме они определяют следующее действие пользователя. ваш подход не сработает. как быть дальше?
на основании опыта предположу что таких ситуаций сильно больше 50%. таким образом предполагаю, что с помощью вашего подхода проблему в целом не решить.
+ скриншоты вашей системы подтверждают ( особенно если предположить, что на них показаны только нужные данные) — интерфейс не получается простым.
Интерфейс не получается простым? Естественно он не состоит из одной кнопки, но он исполняет только свою функцию.
Если интерфейс имеет в себе несколько фильтров, найденный список и детали одного элемента в списке и меет в себе пару клавиш управления (выбрать, использовать для чего-то), то это не то, что делает интерфейс сложным.
Сложным интерфейс делает разрозненное количество различных возможностей, которые не сгруппированы логически ни в какую функцию. Интерфейс может выглядеть просто (иметь несколько клавиш и пару другую элементов с данными, текстовые поля или списки с выбором), но в тоже время этот интерфейс может быть очень и очень перегруженным количеством функций, которые он выполняет.
Например можно сделать один экран, где выполняются несколько разных функций над данными в зависимости например от последовательности использования контролей. Какие-то комбинации приведут к изменению данных, какие-то к выводу данных, какие-то к добавлению данных, и при чем можно даже иметь один экран, в котором меняются самые различные данные, и для того чтобы знать что именно получится, нужно знать весь контекст использования данных в этой системе.
Если же говорить на примере моих систем, то любой экран, как бы он не выглядел, не делает этого. Если экран выглядит сложно, это не значит что он делает разные разрозненные вещи. Экран приведенный ниже имеет на себе всевозможные фильтры для поиска среди товаров, имеет список товаров и имеет одну функцию: выбор товаров.
То есть в этом экране не возможно добавить или изменить или удалить товар, в нем нельзя добавить или убрать или изменить документ, в нем нельзя сделать что-то, что вообще к товару не имеет отношения. В реальности экран очень прост для пользователя, нет никаких пиктограм, картинок, спрятанных функций.
Полностью каждая функция на виду: набор фильтров. Эти фильтры используются для максимальной скорости работы, поэтому они все показаны. Но функция одна: выбрать набор товаров.
В этот экран можно попасть возможно из 3 различных контекстов: создание накладной, переучета или списания (а значит подбор товара путем поиска в каталоге), просто просмотр каталога и распечатка данных товара (ценники, штрих этикетки). Все эти функции имеют одно и тоже значение: нахождение одного или более одного товара и использование его в контексте функции, из которой попал в этот экран.
Конечно это не ERP система сама по себе, это управление одним магазином, но используются теже самые принципы, нет ничего отличного от этих принципов создания экранов с точно заданной функцией.
Если интерфейс имеет в себе несколько фильтров, найденный список и детали одного элемента в списке и меет в себе пару клавиш управления (выбрать, использовать для чего-то), то это не то, что делает интерфейс сложным.
Сложным интерфейс делает разрозненное количество различных возможностей, которые не сгруппированы логически ни в какую функцию. Интерфейс может выглядеть просто (иметь несколько клавиш и пару другую элементов с данными, текстовые поля или списки с выбором), но в тоже время этот интерфейс может быть очень и очень перегруженным количеством функций, которые он выполняет.
Например можно сделать один экран, где выполняются несколько разных функций над данными в зависимости например от последовательности использования контролей. Какие-то комбинации приведут к изменению данных, какие-то к выводу данных, какие-то к добавлению данных, и при чем можно даже иметь один экран, в котором меняются самые различные данные, и для того чтобы знать что именно получится, нужно знать весь контекст использования данных в этой системе.
Если же говорить на примере моих систем, то любой экран, как бы он не выглядел, не делает этого. Если экран выглядит сложно, это не значит что он делает разные разрозненные вещи. Экран приведенный ниже имеет на себе всевозможные фильтры для поиска среди товаров, имеет список товаров и имеет одну функцию: выбор товаров.
То есть в этом экране не возможно добавить или изменить или удалить товар, в нем нельзя добавить или убрать или изменить документ, в нем нельзя сделать что-то, что вообще к товару не имеет отношения. В реальности экран очень прост для пользователя, нет никаких пиктограм, картинок, спрятанных функций.
Полностью каждая функция на виду: набор фильтров. Эти фильтры используются для максимальной скорости работы, поэтому они все показаны. Но функция одна: выбрать набор товаров.
В этот экран можно попасть возможно из 3 различных контекстов: создание накладной, переучета или списания (а значит подбор товара путем поиска в каталоге), просто просмотр каталога и распечатка данных товара (ценники, штрих этикетки). Все эти функции имеют одно и тоже значение: нахождение одного или более одного товара и использование его в контексте функции, из которой попал в этот экран.
Конечно это не ERP система сама по себе, это управление одним магазином, но используются теже самые принципы, нет ничего отличного от этих принципов создания экранов с точно заданной функцией.
тоесть вы рекомендуете некий принцип, а сами ему не следуете, потому, что не позволяет решить несколько бизнес задач на одном экране, я правильно понимаю?
Неправильно, каким образом не следую? Как раз следую, экран должен иметь главную функцию и он ее имеет — выбор списка товаров.
Если это выбор списка товаров, то зачем там история перемещений, история инвентаризаций и еще какието истории? из них тоже товары выбираются?
Быстрый просмотр деталей по товару, перейдя на товар в списке можно увидеть все детали касающиеся товара в нижней секции. Это включает цены входа, выхода, штрих кода, категоризацию и списки документов, в которых эти товары присутствовали. Весьма редко, но используется и главное не мешает функции никаким образом: выбор товаров в список.
вот в это и противоречие. если у вас ( при декларируемом вами подходе — показываем только нужное) в диалоге выбора товаров присутствуют контролы (как вы пишете редко используемые) с полной инфой по товару и они явно делают сам диалог сильно тяжелее для восприятия.
но думаю мы уже начинаем ходить по кругу.
но думаю мы уже начинаем ходить по кругу.
Вряд-ли можно согласиться всем со всеми по каждому пункту, я считаю что у каждого экрана есть своя функция, в данном случае она есть и используется каждый день сотни раз десятками людей. Я не претендую на бесконечность совершенства или что-то в этом рода, я говорю о принципе, которому следую. Есть смысл и в том, чтобы ощущать когда принципу нужно следовать 99%, а когда 98%, возможно здесь кроется интуиция или наблюдение за использованием?
Добавлю что на экране приведенном ниже только необходимое. Пользователи иногда требуют информацию об истории товара (накландых, списаний, переучетов), когда они выбирают товары для своих нужд. Таким образом хотя это и редкий случай, иногда пользователи просматривают историю документов для товара, прежде чем использовать товар для своих целей.
Те скрины, которые опубликованны на Вашем сайте, как примеры Вашей системы, вроде этого, скорее выглядят перегруженными.
Что помешало Вам применить принцип «разделения функционала по разным окнам» в своей системе?
Ведь, как я понял, эту систему Вы поставляете в коробочном варианте, т.е. это окно не следствие внедрения и пятилетних доработок?
Что помешало Вам применить принцип «разделения функционала по разным окнам» в своей системе?
Ведь, как я понял, эту систему Вы поставляете в коробочном варианте, т.е. это окно не следствие внедрения и пятилетних доработок?
Ответил выше на это. В двух словах: это экран для фильтрации списка товаров, нахождения товаров, это и есть функция того конкретного экрана.
Если смотреть на тот конкретный интефейс, то он имеет на себе все элементы, ничего спрятанного, фактически нет сложных контекстовых меню, все полностью на виду. Мы говорим о высокой текучке кадров в магазине, это экран интерфейса управлением магазина, там нет иконок, пиктограм, только слова. Текстовые поля и списски для фильтров и есть возможность использовать subset (небольшое кол-во) упращенных регулярных выражений для быстрого поиска, что оказалось очень сподручным для администраторов и директоров, но это потребовало страницы с помощью по использования этих выражений, это не является интуитивным, поэтому требует обьяснения.
Нет причины разбивать этот экран на большее количество, его функция одна (выбор товаров в список), а детали приведенные ниже иногда полезны. Решение коробочное, используется 2.5 года и очень простое (это визуальная часть системы для управления отдельным магазином, серверная часть тоже в магазине и интефейс может быть заменен. Магазинная серверная часть 'разговаривает' с центральной серверной системой для обмена данными и контроля, например для принятия новых товаров, изменения цен, получения импортированных электронных накладных, перемещений, все это прозрачно для пользователей, включая обновления данных в кассы и другие приборы).
Даже этот интерфейс прост, в его меню (то что по верху экрана) есть только абсолютный минимум, только то что конкретно необходимо для работы в магазине, но не более того.
Если смотреть на тот конкретный интефейс, то он имеет на себе все элементы, ничего спрятанного, фактически нет сложных контекстовых меню, все полностью на виду. Мы говорим о высокой текучке кадров в магазине, это экран интерфейса управлением магазина, там нет иконок, пиктограм, только слова. Текстовые поля и списски для фильтров и есть возможность использовать subset (небольшое кол-во) упращенных регулярных выражений для быстрого поиска, что оказалось очень сподручным для администраторов и директоров, но это потребовало страницы с помощью по использования этих выражений, это не является интуитивным, поэтому требует обьяснения.
Нет причины разбивать этот экран на большее количество, его функция одна (выбор товаров в список), а детали приведенные ниже иногда полезны. Решение коробочное, используется 2.5 года и очень простое (это визуальная часть системы для управления отдельным магазином, серверная часть тоже в магазине и интефейс может быть заменен. Магазинная серверная часть 'разговаривает' с центральной серверной системой для обмена данными и контроля, например для принятия новых товаров, изменения цен, получения импортированных электронных накладных, перемещений, все это прозрачно для пользователей, включая обновления данных в кассы и другие приборы).
Даже этот интерфейс прост, в его меню (то что по верху экрана) есть только абсолютный минимум, только то что конкретно необходимо для работы в магазине, но не более того.
Если для каждой задачи делать «экран», то эти полторы тысячи экранов будут довольно разношерстными. Их будут дорабатывать в разное время, разные люди с разным уровнем понимания задачи.
Ну и плюс стоимость. Сделать и ПОДДЕРЖИВАТЬ полторы тысячи экранов примерно в 100 раз сложнее чем 15.
Те люди, которые будут принимать решение об оплате захотят увидеть альтернативу. И если альтернатива — «захламленное окно», будет в 100 раз дешевле, то who cares?
Или вы не пишите системы, в которых полторы тыс. разных видов справочников и документов?
Ну и плюс стоимость. Сделать и ПОДДЕРЖИВАТЬ полторы тысячи экранов примерно в 100 раз сложнее чем 15.
Те люди, которые будут принимать решение об оплате захотят увидеть альтернативу. И если альтернатива — «захламленное окно», будет в 100 раз дешевле, то who cares?
Или вы не пишите системы, в которых полторы тыс. разных видов справочников и документов?
Как раз наоборот, увеличение количества различных данных в системе должно вести к увеличению методов контроля (тех же экранов с разной функциональностью). Чем больше различных данных в системе, тем важнее их разделение на отдельные секции, отдельные методы использования, отдельные разрешения различным пользователям. Это именно упрощает работу, доработку, определение задач, а не усложняет. Работать над небольшой секцией программы проще, чем сразу над всеми ее частями.
Смотрите, у любого действия должен быть какой-то естественный стопор. Например, если для простой системы будет 1 млн. окон, то это — плохо, т.к. при доработках пользователю придется перечислять все места, где нужно внести изменения и он упустит примерно 900 тыс. мест.
Т.е. вам нужно, хотя бы для себя, сформулировать мысль: «А на сколько хорошо разделять систему на блоки? Где должна пройти граница между ними? Как я принимаю решение о том, что данную функциональность я вношу в этот модуль, а в каком случае выделяю в отдельный?».
В этой статье я попытался донести мысль, что при реальных внедрениях сложных учетных систем часто нет тех людей, которые могут сформулировать такую мысль.
Т.е. вам нужно, хотя бы для себя, сформулировать мысль: «А на сколько хорошо разделять систему на блоки? Где должна пройти граница между ними? Как я принимаю решение о том, что данную функциональность я вношу в этот модуль, а в каком случае выделяю в отдельный?».
В этой статье я попытался донести мысль, что при реальных внедрениях сложных учетных систем часто нет тех людей, которые могут сформулировать такую мысль.
тут еще есть момент того, что ролю людей в больших компаниях часто изменяются. вчера кладовщик вася работал себе, а сегодня он замещает кладовщика петю, который имел право чтото отпускать и рррраззз — вася видит совсем другие экраны. васе страшно, да.
То есть Васе дают доступ к системе под пользователем Пети? Возможно это опрометчиво, но если в этом есть необходимость, а Вася раньше не делал такой работы, которой занимался Петя, то зачем Васе нужны были секции системы, в которых у него не было необходимости?
Да, так и есть. Вчера человек был администратором в магазине А, сегодня его перевели и сделали директором в магазине Б. У него вчера был другой доступ и функций на экране меньше отражалось, а сегодня у него возможно и доступ выше к данным и функций возможно больше и еще ему дали доступ к другой части системы через другой вход вообще, которой он раньше не видел и не занимался, а теперь придется научится.
Удивительно, не правда ли? Это как водитель грузовика, которого взяли и перевели работать пилотом самолета и перед ним больше функций появилось. Ужас! Нужно было все эти рычаги, приборы ему еще в грузовике прицепить, чтобы привыкал заранее.
Да, так и есть. Вчера человек был администратором в магазине А, сегодня его перевели и сделали директором в магазине Б. У него вчера был другой доступ и функций на экране меньше отражалось, а сегодня у него возможно и доступ выше к данным и функций возможно больше и еще ему дали доступ к другой части системы через другой вход вообще, которой он раньше не видел и не занимался, а теперь придется научится.
Удивительно, не правда ли? Это как водитель грузовика, которого взяли и перевели работать пилотом самолета и перед ним больше функций появилось. Ужас! Нужно было все эти рычаги, приборы ему еще в грузовике прицепить, чтобы привыкал заранее.
Возможно в вашей системе и приходится давать доступ от другого пользователя, а в обычных ерп, просто прав добавляют ( или ролей).
Васе вчера они были не нужны, но вот с сегодняшнего дня петя в отпуске, начальник подписал приказ о том что вася петю замещает, админ зашел в консольку и добавли васе прав. вася логинится и… «але админ, а че у меня тут картинка другая?».
у вас в компании часто водителей грузовиков в пилоты берут работать? клиенты не жалуются?:)
Васе вчера они были не нужны, но вот с сегодняшнего дня петя в отпуске, начальник подписал приказ о том что вася петю замещает, админ зашел в консольку и добавли васе прав. вася логинится и… «але админ, а че у меня тут картинка другая?».
у вас в компании часто водителей грузовиков в пилоты берут работать? клиенты не жалуются?:)
Возможно в вашей системе и приходится давать доступ от другого пользователя, а в обычных ерп, просто прав добавляют ( или ролей).— это из вашего же комментария. В моей системе человеку добавят ролей (и прав доступа к данным разных магазинов например).
То что я написал ответ на ваш же комментарий. «Вася работал себе и вдруг теперь работает за Петю и видит больше функциональности и данных чем раньше».
Как раз мой к вам вопрос и был: почему Вася должен был видеть раньше то, чем занимался Петя, если у Васи явно не было в этом необходимости?
например чтобы в случае отсутствия пети, вася влился в работу быстрее. тоесть передача знаний петей будет примерно такой. вот на том экране у тебя «рассерятся» поля А, Б, В и в них вводишь то-то и все. В вашем случае петя сначала должен будет посмотеть — а каким в итоге будет гуй у васи. что ему покажут, а что нет.
но в целом шире: экраны в ерп делаются не просто так, чтобы показать данные. экран описывает стадии какогото процесса и если ты участник процесса, то тебе очень часто полезно видеть все данные. даже если ты в итоге вводишь в одно поле 5 циферок и нажимаешь «ок».
но в целом шире: экраны в ерп делаются не просто так, чтобы показать данные. экран описывает стадии какогото процесса и если ты участник процесса, то тебе очень часто полезно видеть все данные. даже если ты в итоге вводишь в одно поле 5 циферок и нажимаешь «ок».
например чтобы в случае отсутствия пети, вася влился в работу быстрее.— это вопрос не системный, а операционный. Нужно ли Васе и Пете видить одни и те же данные или экраны и элементы управления.
Еще раз, если у этих двух рабочих похожая задача, то почему у них настолько различные контрольные элементы? Если они отличаются только доступом к кол-ву данных, то вряд-ли между их работой существует большая разница (например один из них обслуживает фирму А и другой фирму Б, обе фирмы являются одной и тойже компанией, но там разные товары идут).
Давайте так: есть кассир и старший кассир. Например касса настроена так, что только старший кассир может делать какую-то функцию (например выписывать товарный чек или делать возврат), а кассир не может этого делать в своей роли.
Старший кассир не пришел, а нужно сделать возврат. Кассиру разрешили делать возврат. Что за систему вы предлагаете, где кассир и может и не может делать возврат одновременно, пока он находится в роли кассира?
гм, я не совсем понял постановку задачи.
если кассиру добавили прав на операцию возврата, то почему он не может сделать возврат?
тем более я не понял — где я это предлагаю?
если кассиру добавили прав на операцию возврата, то почему он не может сделать возврат?
тем более я не понял — где я это предлагаю?
Ваш пример имел в себе Петю и Васю. Вы говорили о добавлении прав (или функциональности доступной) одного другому. Я привел более точный пример: кассир, который не имеет прав на возврат и старший кассир, который может сделать возврат.
Старший кассир не показался на работе, как в вашем примере о Васе, и теперь Петя (кассир) должен делать возврат, но у него не было таких прав, он был кассир, но не старший. Пете добавили прав, он теперь как старший кассир может делать возврат. Теперь он видит эту функциональность и с ваших слов (цитирую):
мой вопрос: что здесь удивительного, что один человек в системе заменяет другого и у него появляются новые функции на экране, которых он раньше не видел по причине того, что раньше он с ними не работал?
И если вы считаете что кассир должен быть в состоянии заменить старшего кассира (и это часто так и случается, нет ничего в этом удивительного, это нормальный процесс на производстве), то значит кассир не должен быть отпугнут экраном, где появились новые функции, доступные старшему кассиру.
Если же вы считаете что ничего не должно появляться нового, на экране у человека, которому добавили прав в системе, то обьясните почему? Он не должен иметь возможность пользоваться функциональностью, которую ему не разрешают. Да, при изменении прав у него появляется новая функциональность. Я устал этот пример разжевывать, чесно говоря очень странно что приходится.
Старший кассир не показался на работе, как в вашем примере о Васе, и теперь Петя (кассир) должен делать возврат, но у него не было таких прав, он был кассир, но не старший. Пете добавили прав, он теперь как старший кассир может делать возврат. Теперь он видит эту функциональность и с ваших слов (цитирую):
а сегодня он замещает кладовщика петю, который имел право чтото отпускать и рррраззз — вася видит совсем другие экраны. васе страшно, да.
мой вопрос: что здесь удивительного, что один человек в системе заменяет другого и у него появляются новые функции на экране, которых он раньше не видел по причине того, что раньше он с ними не работал?
И если вы считаете что кассир должен быть в состоянии заменить старшего кассира (и это часто так и случается, нет ничего в этом удивительного, это нормальный процесс на производстве), то значит кассир не должен быть отпугнут экраном, где появились новые функции, доступные старшему кассиру.
Если же вы считаете что ничего не должно появляться нового, на экране у человека, которому добавили прав в системе, то обьясните почему? Он не должен иметь возможность пользоваться функциональностью, которую ему не разрешают. Да, при изменении прав у него появляется новая функциональность. Я устал этот пример разжевывать, чесно говоря очень странно что приходится.
я уже ответил на этот ваш вопрос вот тут habrahabr.ru/post/172073/#comment_5975783
Не представляю себе систему с 1,000,000 окон, но всякое бывает. Наверное такую систему имеет смысл разбить на несколько систем, наверное там слишком много совсем не относящихся друг к другу данных и функций и скорее всего большинству пользователей все равно нужно только 5-20 различных секций (и может быть максимум 20-50 экранов). Это же инструмент, а люди это работники, у них есть задачи и задачи не безлимитны.
Вопрос именно в том: какие типы данных и пользователей существует и чем разные типы пользователей занимаются. Отсюда и идет разделение системы на логические секции. Данные могут накапливаться в системе не обращая внимания на пользователей, но пользователям не нужны лишние данные и лишние функции в их секциях.
Если же нет тех людей, которые могут хоть как-то это сформулировать для конкретной компании, то тогда о каких 'сложных учетных системах' может идти речь? Тогда сложность системы состоит не в общем количестве функционала, данных и различных методах использования, но только в сложности использования системы для любых ситуаций и функций вообще.
Вопрос именно в том: какие типы данных и пользователей существует и чем разные типы пользователей занимаются. Отсюда и идет разделение системы на логические секции. Данные могут накапливаться в системе не обращая внимания на пользователей, но пользователям не нужны лишние данные и лишние функции в их секциях.
Если же нет тех людей, которые могут хоть как-то это сформулировать для конкретной компании, то тогда о каких 'сложных учетных системах' может идти речь? Тогда сложность системы состоит не в общем количестве функционала, данных и различных методах использования, но только в сложности использования системы для любых ситуаций и функций вообще.
Это случайно не Ваше?
В таком случае этой системе не понадобилось внедрений и доработок :)
В таком случае этой системе не понадобилось внедрений и доработок :)
Совершенно верно, это клиентская часть одной из систем (управление отдельным магазином, то есть это используется в отдельно-стоящем магазине) и там не было доработок, экран существует в этом виде уже 2.5 года. Экран имеет в себе динамически сгенерированную часть (где даны списки 'Бренд', 'Категория' и т.п.) эти детали генерируются из данных, которые добавляются в другой системе. Верхняя часть это фильтры, средняя часть это список и нижняя часть это детали. Список состоит из товаров и в деталях можно увидеть любой из документов, соответствующий этим товарам.
Этот же экран используется из нескольких других экранов (если нужно найти товар подборкой для накладной например), здесь можно выбрать один или большее кол-во товаров для нескольких нужд (распечатка, создание переучета или списания или накладной). Общий экран с товарами.
Как клиентский интерфейс, это можно заменить 'легким' экраном в браузере или любой другой своей программой. Серверная часть этого инструмента дает доступ к своим функциям сетевыми услугами (web service). Экран используется с любой из машин магазина и система позволяет работать над любым документом больше чем одному пользователю одновременно.
Этот же экран используется из нескольких других экранов (если нужно найти товар подборкой для накладной например), здесь можно выбрать один или большее кол-во товаров для нескольких нужд (распечатка, создание переучета или списания или накладной). Общий экран с товарами.
Как клиентский интерфейс, это можно заменить 'легким' экраном в браузере или любой другой своей программой. Серверная часть этого инструмента дает доступ к своим функциям сетевыми услугами (web service). Экран используется с любой из машин магазина и система позволяет работать над любым документом больше чем одному пользователю одновременно.
>>Например, если для простой системы будет 1 млн. окон, то это — плохо
Откуда может взяться в одной системе миллион окон?
>>то это — плохо, т.к. при доработках пользователю придется перечислять все места, где нужно внести изменения и он упустит примерно 900 тыс. мест.
Что за изменения такие, которые требуют переписывать всю систему разом?
>>Т.е. вам нужно, хотя бы для себя, сформулировать мысль: «А на сколько хорошо разделять систему на блоки? Где должна пройти граница между ними? Как я принимаю решение о том, что данную функциональность я вношу в этот модуль, а в каком случае выделяю в отдельный?». >>>
Как я понял под блоками имеется ввиду всего лишь разный интерфейс для различных пользователей. Их не миллион штук. На любом предприятии людей можно разделить по зонам ответственности — кадровики, менеджеры, финансисты, бухгалтера, заведующие складом, кассиры, мастера смены и т.д. Каждому из них требуется ограниченное количество документов и отчетов. И для каждой группы создаются определенные интерфейсы со ссылками на необходимые документы, справочники, отчеты + какой-то полный интерфейс с доступом ко всему сразу. А документы могут быть одними и теми же для всех пользователей. Реализация товаров может потребоваться и менеджеру и бухгалтеру и финансисту и заведующему складу, нет необходимости для каждого создавать свой уникальный документ.
Откуда может взяться в одной системе миллион окон?
>>то это — плохо, т.к. при доработках пользователю придется перечислять все места, где нужно внести изменения и он упустит примерно 900 тыс. мест.
Что за изменения такие, которые требуют переписывать всю систему разом?
>>Т.е. вам нужно, хотя бы для себя, сформулировать мысль: «А на сколько хорошо разделять систему на блоки? Где должна пройти граница между ними? Как я принимаю решение о том, что данную функциональность я вношу в этот модуль, а в каком случае выделяю в отдельный?». >>>
Как я понял под блоками имеется ввиду всего лишь разный интерфейс для различных пользователей. Их не миллион штук. На любом предприятии людей можно разделить по зонам ответственности — кадровики, менеджеры, финансисты, бухгалтера, заведующие складом, кассиры, мастера смены и т.д. Каждому из них требуется ограниченное количество документов и отчетов. И для каждой группы создаются определенные интерфейсы со ссылками на необходимые документы, справочники, отчеты + какой-то полный интерфейс с доступом ко всему сразу. А документы могут быть одними и теми же для всех пользователей. Реализация товаров может потребоваться и менеджеру и бухгалтеру и финансисту и заведующему складу, нет необходимости для каждого создавать свой уникальный документ.
Хотя в целом, подход конечно, правильный для систем, вроде www.moedelo.org/
Для разных типов работ пользователям нужно будет входить в разные экраны.
Так так и есть. А для входа в каждый «экран» кнопочка в тулбаре :) Можно сделать ярлык на рабочем столе, но сути это не меняет: если проектируем GUI, то для входа в экран должен быть визуальный маркер, а поскольку экранов много, то эти маркеры засирают рабочее пространство.
Я решаю эту проблему простым способом группирования функциональности в логические секции и разделением пользовательских ролей. Пользователи видят только то, с чем им нужно работать. Это помогает и визуально, но также предотвращает ненужные движения пользователя в контрольных секцияx, где ему нечего делать. Большинство пользователей никогда и не видят как выглядит система в полном обьеме кроме специфических супер-пользователей.
Что-то Вы очень негативно описываете ситуацию.
Естественно, что решение о внедрении того или иного продукта управления принимается теми людьми, которые максимум будут смотреть отчеты верхнего уровня. Это финансы. Представьте картину: «Василий, инженер-программист 3-го разряда, в пору своих недюжинных способностей долго был угрюм по поводу организации бизнес-процессов компании. И вот на одном совещании в баре ему пришла гениальная мысль. Всё! Решено! Завтра покупаем системку за 1,5 миллиона! Потом пара недель, и всё!».
Имеется некоторый опыт как по разработке и расширению коробок, так и написанию систем с нуля, и чуть менее по разработке самих коробок. Коим я и хочу с Вами поделиться.
Этот опыт дал мне возможность взглянуть на происходящее с разных сторон.
Разработка на основе коробок — несомненный плюс скорость как разработки, так и внедрения, при наличии уже большого количества решенных задач с велосипедами. Минус — это ограничения накладываемые самой коробкой, тут и способ организации, и способы вмешательства в работу системы и т.д.
Системы с нуля — это уникальность. Интерфейс и организация более адаптированы. Можно увидеть конфетку, где каждая кнопка имеет жесткий смысл и необходимость. Минус — время, причем множитель хороший.
Разработка коробок — это специфическая разработка. Вы должны покрывать множество требований. С большой вероятностью ни один клиент не будет знать систему полностью, даже на уровне пользователя. Знакомый пример: «В среднем пользователи Word используют 10-15% его возможностей».
Давайте вспомним зачем внедряют системы управления. Управление (правда странно?), автоматизация «мартышкиного труда» (чтобы не было недопонимания, я говорю о ручных машинальных однотипных действиях, которые сжирают время), контроль ситуации в минимальные сроки, оценка различными мерами (в зависимости от целевой задачи), и т.д.
Решение задач на 100% — это миф и утопия. Но, если вы выиграете 30% времени работы сотрудников, освободив их от скучных дел, разве плохо? Или если это снизит количество авралов на 40% — разве «посиделки с друзьями/свидания/ и т.д.» не стоят того? Не говоря о том, что компания в этом случае тоже выигрывает.
А вот теперь самое главное. Человеческий фактор. Вы никуда и никогда от него не денетесь. «Петрович негодует! Что это за система, где нет кнопки — добавить котят! Он же видел в интернете, что это мейнстрим!!!»/«Федоровна недовольна! Как это она обязана указывать возраст! Это же чистой воды хамство!»/«Милая Анастасия не признает системы, где нельзя поставить лайк! Это ущемление ее социальных прав!»/ и т.д.
Думаю более жесткие варианты человеческого аспекта итак легко представить.
А теперь возьмите все это вместе. Потрясите в мешке. Потом еще. И еще капельку. А потом еще немного. А затем еще чуть-чуть. Вы думали все? А теперь покидайте! Еще! Выше! Веселей! Ну, вот теперь этот клубок начинает быть похожим на реальность.
Поэтому важнее, что Вы сделали, чтобы появился торт, чем то, что сделано для того, чтобы сварились пельмени;)
Естественно, что решение о внедрении того или иного продукта управления принимается теми людьми, которые максимум будут смотреть отчеты верхнего уровня. Это финансы. Представьте картину: «Василий, инженер-программист 3-го разряда, в пору своих недюжинных способностей долго был угрюм по поводу организации бизнес-процессов компании. И вот на одном совещании в баре ему пришла гениальная мысль. Всё! Решено! Завтра покупаем системку за 1,5 миллиона! Потом пара недель, и всё!».
Имеется некоторый опыт как по разработке и расширению коробок, так и написанию систем с нуля, и чуть менее по разработке самих коробок. Коим я и хочу с Вами поделиться.
Этот опыт дал мне возможность взглянуть на происходящее с разных сторон.
Разработка на основе коробок — несомненный плюс скорость как разработки, так и внедрения, при наличии уже большого количества решенных задач с велосипедами. Минус — это ограничения накладываемые самой коробкой, тут и способ организации, и способы вмешательства в работу системы и т.д.
Системы с нуля — это уникальность. Интерфейс и организация более адаптированы. Можно увидеть конфетку, где каждая кнопка имеет жесткий смысл и необходимость. Минус — время, причем множитель хороший.
Разработка коробок — это специфическая разработка. Вы должны покрывать множество требований. С большой вероятностью ни один клиент не будет знать систему полностью, даже на уровне пользователя. Знакомый пример: «В среднем пользователи Word используют 10-15% его возможностей».
Давайте вспомним зачем внедряют системы управления. Управление (правда странно?), автоматизация «мартышкиного труда» (чтобы не было недопонимания, я говорю о ручных машинальных однотипных действиях, которые сжирают время), контроль ситуации в минимальные сроки, оценка различными мерами (в зависимости от целевой задачи), и т.д.
Решение задач на 100% — это миф и утопия. Но, если вы выиграете 30% времени работы сотрудников, освободив их от скучных дел, разве плохо? Или если это снизит количество авралов на 40% — разве «посиделки с друзьями/свидания/ и т.д.» не стоят того? Не говоря о том, что компания в этом случае тоже выигрывает.
А вот теперь самое главное. Человеческий фактор. Вы никуда и никогда от него не денетесь. «Петрович негодует! Что это за система, где нет кнопки — добавить котят! Он же видел в интернете, что это мейнстрим!!!»/«Федоровна недовольна! Как это она обязана указывать возраст! Это же чистой воды хамство!»/«Милая Анастасия не признает системы, где нельзя поставить лайк! Это ущемление ее социальных прав!»/ и т.д.
Думаю более жесткие варианты человеческого аспекта итак легко представить.
А теперь возьмите все это вместе. Потрясите в мешке. Потом еще. И еще капельку. А потом еще немного. А затем еще чуть-чуть. Вы думали все? А теперь покидайте! Еще! Выше! Веселей! Ну, вот теперь этот клубок начинает быть похожим на реальность.
Поэтому важнее, что Вы сделали, чтобы появился торт, чем то, что сделано для того, чтобы сварились пельмени;)
Признаюсь, у меня не получилось выхватить основную мысль. Не могли бы Вы ее в два-три предложения сформулировать? Очень хочется понять.
Окей, постараюсь немного по другому описать.
Чем дороже стоимость проекта, тем длиннее путь самого проекта. И тем большее количество людей вовлечены в проект. При этом каждый человек преследует свои цели. Цели эти могут и противоречить.
Приведу абстрактный пример. У продавца задача как можно больше и дороже продать. От этого зависит сколько он получит денег. Поэтому для него 30 кнопок — это отлично. Программист хочет создавать красивые и уникальные решения. И для него немаловажна эстетика. Поэтому для него 30 кнопок — это фарш. Пользователь хочет избавиться от рутины, и сделать свою работу более удобной. Для него 30 кнопок — это не самое прекрасное решение, но все же облегчает жизнь. И каждый из них отчасти прав.
Допустим Вы программист. Просто доказывать продавцу, что 30 кнопок это фарш — бесполезно. Тем более продавец сам прекрасно может это понимать. И итог — Вы будете писать 30 кнопок. А можете сделать свою работу и показать, что Вы знаете свое дело. Т.е. не просто говорить, что 30 кнопок — это фарш. А придумать и накидать демо пример в каком-нить редакторе изображений (банальный скриншот), который будет выглядеть красиво, решать все те же задачи, и быть более удобным. По финансам будет скорее всего примерно так же стоить, а может и немного дороже. Тогда у продавца будет возможность показать аналог интерфейса. И заказчик скорее всего выберет его, потому что ему этим пользоваться. И итог — есть большая вероятность, что Вы будете делать то, что придумали.
Еще раз повторюсь.
Поэтому важнее, что Вы сделали, чтобы появился торт, чем то, что сделано для того, чтобы сварились пельмени;)
Чем дороже стоимость проекта, тем длиннее путь самого проекта. И тем большее количество людей вовлечены в проект. При этом каждый человек преследует свои цели. Цели эти могут и противоречить.
Приведу абстрактный пример. У продавца задача как можно больше и дороже продать. От этого зависит сколько он получит денег. Поэтому для него 30 кнопок — это отлично. Программист хочет создавать красивые и уникальные решения. И для него немаловажна эстетика. Поэтому для него 30 кнопок — это фарш. Пользователь хочет избавиться от рутины, и сделать свою работу более удобной. Для него 30 кнопок — это не самое прекрасное решение, но все же облегчает жизнь. И каждый из них отчасти прав.
Допустим Вы программист. Просто доказывать продавцу, что 30 кнопок это фарш — бесполезно. Тем более продавец сам прекрасно может это понимать. И итог — Вы будете писать 30 кнопок. А можете сделать свою работу и показать, что Вы знаете свое дело. Т.е. не просто говорить, что 30 кнопок — это фарш. А придумать и накидать демо пример в каком-нить редакторе изображений (банальный скриншот), который будет выглядеть красиво, решать все те же задачи, и быть более удобным. По финансам будет скорее всего примерно так же стоить, а может и немного дороже. Тогда у продавца будет возможность показать аналог интерфейса. И заказчик скорее всего выберет его, потому что ему этим пользоваться. И итог — есть большая вероятность, что Вы будете делать то, что придумали.
Еще раз повторюсь.
Поэтому важнее, что Вы сделали, чтобы появился торт, чем то, что сделано для того, чтобы сварились пельмени;)
Я тоже мысль потерял где то на втором абзаце. Where is sliver bullet?
Некорректно сравнивать приложения, направленные на обычных пользователей и на корпоративный рынок. Совершенно разные условия приемки конечного результата.
Чтобы интерфейс был дружелюбен к корпоративному пользователю нужно, как минимум, выполнить следующие требования:
1. Польза от юзабилити должна быть ощутима в рублях. Иначе это выкинутые деньги на ветер, по мнению топ менеджмента.
(Как пример: приложения кассиров РЖД, там исключено управление мышкой и интерфейс оптимизирован под хоткеи и наиболее частые операции. Время — деньги!)
2. Разработчик должен разбираться в предметной области лучше чем заказчик, что скорее исключение, чем правило.
3. У разработчика должен быть больший авторитет, чем у линейных руководителей заказчика. Пользователи никогда не анализировали свою работу с приложением, т.е. какие операции наиболее частые, какие поля нужны, а какие нет. Тем более если приложение еще не внедрено. В этой связи никакой линейный руководитель не пойдет и не скажет «Ребят нам это требование или поле не нужно… давайте вычеркнем его из ТЗ». (Случаи такие бывают, но тоже как исключение). В этой связи все работают по правилу: «Лучше перестраховаться, чем потом страдать».
4. Разработчик должен любить свой продукт больше чем деньги.
Чтобы интерфейс был дружелюбен к корпоративному пользователю нужно, как минимум, выполнить следующие требования:
1. Польза от юзабилити должна быть ощутима в рублях. Иначе это выкинутые деньги на ветер, по мнению топ менеджмента.
(Как пример: приложения кассиров РЖД, там исключено управление мышкой и интерфейс оптимизирован под хоткеи и наиболее частые операции. Время — деньги!)
2. Разработчик должен разбираться в предметной области лучше чем заказчик, что скорее исключение, чем правило.
3. У разработчика должен быть больший авторитет, чем у линейных руководителей заказчика. Пользователи никогда не анализировали свою работу с приложением, т.е. какие операции наиболее частые, какие поля нужны, а какие нет. Тем более если приложение еще не внедрено. В этой связи никакой линейный руководитель не пойдет и не скажет «Ребят нам это требование или поле не нужно… давайте вычеркнем его из ТЗ». (Случаи такие бывают, но тоже как исключение). В этой связи все работают по правилу: «Лучше перестраховаться, чем потом страдать».
4. Разработчик должен любить свой продукт больше чем деньги.
Спасибо за статью. Теперь я понял, почему в microsoft dynamics nav всё так запутано :)
Я как-то имел несчастье принимать некоторое участие в разработке т.н. ERP системы (сомневаюсь, что она может считаться настоящим ERP, но заявлялась как таковая). Там всё было по последнему пшику моды тех времён, чтоб значит Web Services и все дела. В архитектуре этой монструозности была так органично заложена SQL-инъекция (куски SQL-запросов передавались вебсервисам), что по-человечески вылечить её было вообще нельзя. Пришлось сделать честный парсер для некоторого подмножества допустимых кусков SQL, чтобы не пропускать вредоносные запросы. Откровенная глупость, но в той ситуации что-то другое было сложно придумать. Ещё было массовое редактирование бесчисленных типовых формочек и хранимок perl-скриптами, да и другие прелести. Меня аж до сих пор коробит, когда вспоминаю эту похабщину, иногда даже хочется, чтобы память отшибло.
На самом деле картинка — всего лишь шутка. В ней, естественно, есть доля правды, но это не значит, что картинка годится для любого случая. Если сравнивать софт с схожим функционалом, например Picasa Web Albums и Flickr, то тогда такие картинки годятся. А если сравнивать какой-нибудь Twitter и 1-С Бухгалтерию, или там ICQ Клиент и софт для складского учёта, понятно, что Твиттер и ICQ клиент будут иметь гораздо более минималистичный интерфейс, но на то есть объективные причины — ни Твиттер ни ICQ количественно не имеют и сотой части функционала, присутвтвующего в софте для всяческого учёта. Основываясь на этой картинке, утверждать что какой-нибудь QIP писали профессионалы, а 1-С Бухгалтерию или SAS соответственно писали уроды криворукие — наивно и глуповато.
Хочу две кнопки «посчитать зарплату» и «получить зарплату»!
Для любого может не относится, но для многих относится. То есть не просто доля есть, а она большАя, если не бОльшая. Одна из причин была озвучена: экономическая нецелесообразность для разработчика создавать индивидуальные или ролевые интерфейсы АРМ. Ещё одну — вынос в постоянно видимые элементы UI, требующиеся очень редко (типа отдельной кнопки на тулбаре «создать готовой отчет»), — явно вроде не озвучили, но тоже имеет место.
Проще говоря, не должен интерфейс постоянно отображать неиспользуемую (в силу роли или прав конкретного сотрудника) или редко используемую функциональность Не должна быть вся функциональность продукта быть доступной за один клик. Но этим часто пренебрегают в силу экономических причин («нам за это не платили, функциональность реализована, и баста», «объяснять бухгалтерам, что такое меню? Нам за это не платили» и т. п.). Отчасти в этом виновата система тендеров или просто желание заказчиков заплатить по минимуму. Отчасти (как следствие) — страх разработчиков увеличивать смету.
Проще говоря, не должен интерфейс постоянно отображать неиспользуемую (в силу роли или прав конкретного сотрудника) или редко используемую функциональность Не должна быть вся функциональность продукта быть доступной за один клик. Но этим часто пренебрегают в силу экономических причин («нам за это не платили, функциональность реализована, и баста», «объяснять бухгалтерам, что такое меню? Нам за это не платили» и т. п.). Отчасти в этом виновата система тендеров или просто желание заказчиков заплатить по минимуму. Отчасти (как следствие) — страх разработчиков увеличивать смету.
При всем том, что картинка полна сарказма со своими кучами кнопок с более-менее одинаковыми названиями, можно заметить, ЧТО
1) приложения и гуи Гугла и Эппла расчитаны на выполнения ограниченного набора функций и созданы для того, чтобы самый тупой пользователь первый раз увидев приложение мог знать куда тут тыкать. Ну или хотябы возможностей тыкнуть НЕ ТУДА была минимальна. При этом нормальна ситуация, если функциональность нужна 10% пользователям, то ее можно и часто нужно выкинуть из приложения вообще или сделать малодоступной.
2) Приложение ЕРП (а так же многие другие энтерпрайз приложения) расчитаны на выполнение более широкого набора функций. Пользователь должен быть обученный, а функциональность нужная 10% пользователям очень часто является критической или хотя бы необходимой для функциональности.
3) Стоимость создания экрана для каждой функции очень часто является достаточно большой. Так же часто получается, что количество экранов становится слишком большим и обучение сотрудников пользоваться/выбирать их становиться сложнее, чем обучить одному, но более сложному интерактивному экрану.
4) В энтерпрайзе приложение решающее 90% требований просто не купят, в экосистеме Эппла и Гугла иметь 2 приложения, которые пересекаются на 80% и имеют 10% своего абсолютно нормально.
Очевидно, что надо дизайн надо разрабатывать и оптимизировать, но подход и требования в энтерпрайз приложениях могут сильно отличаться от подходов и требований к дизайну общеупотребительных приложений.
1) приложения и гуи Гугла и Эппла расчитаны на выполнения ограниченного набора функций и созданы для того, чтобы самый тупой пользователь первый раз увидев приложение мог знать куда тут тыкать. Ну или хотябы возможностей тыкнуть НЕ ТУДА была минимальна. При этом нормальна ситуация, если функциональность нужна 10% пользователям, то ее можно и часто нужно выкинуть из приложения вообще или сделать малодоступной.
2) Приложение ЕРП (а так же многие другие энтерпрайз приложения) расчитаны на выполнение более широкого набора функций. Пользователь должен быть обученный, а функциональность нужная 10% пользователям очень часто является критической или хотя бы необходимой для функциональности.
3) Стоимость создания экрана для каждой функции очень часто является достаточно большой. Так же часто получается, что количество экранов становится слишком большим и обучение сотрудников пользоваться/выбирать их становиться сложнее, чем обучить одному, но более сложному интерактивному экрану.
4) В энтерпрайзе приложение решающее 90% требований просто не купят, в экосистеме Эппла и Гугла иметь 2 приложения, которые пересекаются на 80% и имеют 10% своего абсолютно нормально.
Очевидно, что надо дизайн надо разрабатывать и оптимизировать, но подход и требования в энтерпрайз приложениях могут сильно отличаться от подходов и требований к дизайну общеупотребительных приложений.
2) Но судя по результатам часто считают пользователя либо минимально обученным (что такое меню он не знает, нужна кнопка на тулбаре), либо очень обученным (не нужна ему кнопка? зайдет в конфигуратор и лично для себя её уберет). Проблема в том, что то ли заказчики, то ли разработчики/интеграторы не горят желанием повысить эргономичность интерфейсов даже минимально, предпочитая всю доступную функциональность вынести в однокликовую доступность. вместо, хотя бы, убирания элементов UI в данный момент или данному пользователю в принципе недоступных.
Я даже с этим соглашусь. Но опять же даже оптимизированный интерфейс для энтерпрайз приложений требует больше функций, чем похожее приложение для персонального использования.
Я приведу пример. Вот например почтовое приложение для обработки агентами имейлов в организации. Агенты это колл центр или специализированные только на почту.
В нормальном клиенте функциональность типа темплейтов и категоризации/классификации используется дай бог 10% пользователей. И количество темплейтов минимально. Функция может легко быть вынесена в меню. Смотрим на энтерпрайз приложение:
1) Отдельные темплейты на header, greeting, signature, footer. Причем даже в усеченном виде смешивать нельзя и в каждой категории около 5-10 темплейтов
2) Отдельные темплейты на основной ответ, совмещеный с классификацией сообщений.
При этом это функциональность базовая и необходимая. Данные 2 пункта дают 4 дропдауна на форме + что-то типа кнопки (для просмотра всего дерева темплейтов) с полем быстрого ввода темплейта и полем, где показываются все выбранные основные темплейты с возможностью их удаления. Количество темплейтов доступных агенту может достигать пару сотен штук (а то и больше) и представлять собой дерево в 2-3-5 уровней. Конечно базовый выбор темплейтов происходит автоматически до попадания сообщения агенту, но агент достаточно часто выбирает/добавляет темплейты.
Я приведу пример. Вот например почтовое приложение для обработки агентами имейлов в организации. Агенты это колл центр или специализированные только на почту.
В нормальном клиенте функциональность типа темплейтов и категоризации/классификации используется дай бог 10% пользователей. И количество темплейтов минимально. Функция может легко быть вынесена в меню. Смотрим на энтерпрайз приложение:
1) Отдельные темплейты на header, greeting, signature, footer. Причем даже в усеченном виде смешивать нельзя и в каждой категории около 5-10 темплейтов
2) Отдельные темплейты на основной ответ, совмещеный с классификацией сообщений.
При этом это функциональность базовая и необходимая. Данные 2 пункта дают 4 дропдауна на форме + что-то типа кнопки (для просмотра всего дерева темплейтов) с полем быстрого ввода темплейта и полем, где показываются все выбранные основные темплейты с возможностью их удаления. Количество темплейтов доступных агенту может достигать пару сотен штук (а то и больше) и представлять собой дерево в 2-3-5 уровней. Конечно базовый выбор темплейтов происходит автоматически до попадания сообщения агенту, но агент достаточно часто выбирает/добавляет темплейты.
Пускай так (не знаком со спецификой, темплейты не использую :). Но почему-то кажется, что в интерфейсе этого приложения будет ещё на порядок больше всегда видимых контролов, чем ниспользуется 90% агентами. Банальное форматирование текста (размер шрифта, болд, италик и т. п.), например, которые в повседневной переписке практически никто не использует. Или контролы, которые используются очень редко — например формирование краткого отчета за день (на фоне сотни других).
Кстати пример с форматированием текста достаточно показателен. Пусть он нужен в 10% случаев. Спрячем его подальше, что нормально для пользовательских приложений.
Теперь 10 процентов сообщений обрабатывается на 30 сек дольше. В день обрабатывается допустим 15000 сообщений (это не очень большой объем). Получается 1500*30с=750минут=12.5 часов времени агентов = дополнительно 1.5 агента требуется посадить = 30тыс евро в месяц с налогами.
Это я к тому, что когда дополнительный функционал не замедляет работу, то выносить его куда еще, просто чтобы выглядело красиво и приложение было бы более понятно для неподготовленного пользователя это потеря денег.
Конечно иметь кнопку отчета, которая используется 1 раз в день на основной форме не имеет смысла.
Основная мысль в том, что подход к проектированию ГУИ для пользовательских и энтерпрайз приложений очень различен и играют разные факторы. Если «красивость» и «простота» важны для пользовательский приложений, то для энтерпрайз это не есть основные факторы.
Теперь 10 процентов сообщений обрабатывается на 30 сек дольше. В день обрабатывается допустим 15000 сообщений (это не очень большой объем). Получается 1500*30с=750минут=12.5 часов времени агентов = дополнительно 1.5 агента требуется посадить = 30тыс евро в месяц с налогами.
Это я к тому, что когда дополнительный функционал не замедляет работу, то выносить его куда еще, просто чтобы выглядело красиво и приложение было бы более понятно для неподготовленного пользователя это потеря денег.
Конечно иметь кнопку отчета, которая используется 1 раз в день на основной форме не имеет смысла.
Основная мысль в том, что подход к проектированию ГУИ для пользовательских и энтерпрайз приложений очень различен и играют разные факторы. Если «красивость» и «простота» важны для пользовательский приложений, то для энтерпрайз это не есть основные факторы.
Напомнило книгу «Психбольница в руках пациентов»
Уважаемый Автор, а Вы не пробовали сменить работу?
И дело даже не в том, что в некоторых вопросах вы просто брызжите кипящим маслом от негодования. Дело в том, что Вы явно хотите заниманться чем-то другим.
И дело даже не в том, что в некоторых вопросах вы просто брызжите кипящим маслом от негодования. Дело в том, что Вы явно хотите заниманться чем-то другим.
Вы, наверное, промахнулись веткой? Но даже в этом случае столь критичный комментарий, уверен, не достоин для Вашего ника. Ну и в хабре не приветствуется.
Монах Кассана отправился к Хотэю и поклонился ему. Хотэй ударил монаха по спине. Монах снова поклонился. Хотэй снова ударил его по спине и выгнал прочь. Монах рассказал об этом Кассану.
— Ты понимаешь? — спросил Кассан.
— Нет, — ответил монах.
— Это хорошо. Ведь если бы ты понял, я бы решился дара речи
— Ты понимаешь? — спросил Кассан.
— Нет, — ответил монах.
— Это хорошо. Ведь если бы ты понял, я бы решился дара речи
Из трех представленных на карикатуре интерфейсов реально удобнее пользоваться последним, при условии, что надо много работать с большими объемами данных, а не расшаривать кошечку в инстаграмме. Все профессиональные приложения для работы с СУБД, будь то место оператора приема платежей или оператора интернет-магазина — выглядят именно как третья фотка. И нет тут связи с тем, что «дураки заказывают и равнодушные оплачивают» — автор пытается объяснить объективный процесс «происками зеленых человечков». Если заказчик и разработчик — наиболее заинтересованное в бизнесе лицо — то интерфейс обработки больших объемов точно такой же сложный получится. Оператор учится один раз и потом работает быстро и круто. А все эти юзабилити-шмузабилити штуки нужны для людей, видящих интерфейс первый и возможно последний раз в жизни. Например сайт интернет-магазина или интерфейс игрушки в смертфоне.
Не очень понятно, почему автор сравнивает гугл-поиск (в котором всего одна функция) с бизнес-приложениями (где функций в мельён раз больше). С таким же успехом можно было бы сравнить самолет с колобком и поржать над сложностью первого.
Да ладно. Кроме как на шуточной картинке, с гуглом бизнес-приложение в статье не сравнивается. А как Вы считаете по поводу основной темы статьи: есть ли в целом такая проблема что типовое бизнес приложение (особенно ПОСЛЕ внедрения) имеет скорее избыточно сложный интерфейс чем избыточно простой?
В гуглопоиске есть куча опций, которые в 99% случаев не используются. А в 1% можно и лишние пару кликов сделать, чтобы зайти в расширенный поиск.
Гугл было бы корректней с шеллом сравнивать — и тот, и этот — лишь строка, но функций…
э гугл продукт
<img src="
" alt=«image»/>
<img src="
" alt=«image»/>Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сложность ERP систем