Интересно было ознакомиться со статьей. Хорошо что есть общее описание элементов и верхнеуровневая схема сбора пр. Чего не хватило:
Отличие от других языков описания процессов UML, IDEF0. В каких случаях лучше использовать BPMN? А в каких лучше воздержаться? Фраза Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процесса описывает сценарий но не сравнение
Статья говорит о начале моделирования. При этом на выходе хорошо бы получить модель, которую можно применять. А для этого надо на старте понять сколько это может занять времени. Было бы здорово описать верхнеуровнево/ссылочно оценки трудоемкости описания процесса в этой локации. Насколько долго его описывать (возможно от каких то параметров)?
Ну и про завершение. Как понять, что описан именно нужный процесс с учетом того, что реальные бизнес-пользователи с которых снималась модель могут не знать нотификацию? В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?
Ну так дальше все просто — заходим в AppStore/GooglePlay и ставим приложению одну звезду за надоедающие всплывающие окна. Как только это станет массовым, то приложение начинает сильно терять рейтинг и тратить больше на рекламу. В какой-то момент система придет к равновесию и исключит ненужные уведомления.
Наивный вопрос.
Интересно, а почему нельзя окружить кнопку отправки формы графическими элементами с событием «onMouseOver» тогда при переходе на данное поле будет генерироваться событие — которое меняет параметр, говорящий что пользователь — не робот.
Посмотрел, любопытно. Похоже заточено скорее на торговую деятельность. Закупку, продажу со склада. Хорошо, если получится быть дешевле и удобнее 1С.
Посмотрел блок управления задачами, очень сильные упрощения. Сейчас общаюсь по поводу внедрения Pyrus в разных компаниях, многим нужны последовательности процессов и передача документов между стадиями. У вас это непонятно как сделать. Хотя, могу и ошибаться.
Надо было ї вставлять для повышения уровня надежности :-)
Acronїs — и из нее потом две параллельные прямые вверх могут идти, а из r и ї можно параллельные вниз продолжать
Спасибо за проделанную работу по визуализации работы службы поддержки! Во многом с вами согласен — поддержка не должна плодить проблем на стороне клиента. При этом в статье не описан ключевой вопрос — а зачем оно нужно сотрудникам?
Вдумчивое отношение непрофильного сотрудника к проблеме клиента (как в примере 2) может быть чрезмерной затратой времени сотрудника, при этом он не создаст целевой результат для компании, не получит за это денег.
Мне больше нравится подход — прозрачной переадрессации и невидимых для клиента запросов. Сейчас плотно работаю с Pyrus, поэтому на их примере:
1. Прозрачное перенаправление. Когда пришел запрос, сотрудник переправляет задачу на ответственного за решение, при этом клиент видит кому переправлена задача и как идет по ней ход решения. Все. Это для примера 2.
2. Создание невидимого подзапроса — иногда не надо показывать внутреннюю кухню маршрутизации. Поэтому создается внутренний подзапрос в котором идет разбирательство технической стороны. Клиенту при этом сообщается время ожидания. «Наши специалисты разбираются в ситуации, мы дадим вам ответ в течении ХХХ минут». В случае просрочки — обязательно еще раз связаться с клиентом, извиниться и назвать новый срок.
3. Библиотека стандартных ответов и форм обращения. Из третьего варианта видно, что лучше бы специалистам службы поддержки иметь заготовки вежливых ответов на стандартные вопросы.
Я Pyrus использую.
— есть задачи с подзадачами, сколько угодно уровней;
— можно вносить время по каждой задаче;
— для Андроида и других мобильных платформ есть приложения с оффлайн-синхронизацией (залез в подвал, сделал настройки, отметил время, вылез и оно само синхронизуется);
+ можно группировать задачи в проекты и смотреть расход времени по проекту, а так же динамику.
Обычно задачи не появляются из ниоткуда. Значит их надо вносить в таймтреккер. Поэтому я пользуюсь встроенной функцией учета времени над задачей в Pyrus. Задача пришла, выполнил, записал время. Работает как веб-приложение на десктопах и есть версии под основные мобильные платформы.
Я и не утверждаю, что такая схема является идеальной и подойдет абсолютно всем. Просто интересно наблюдать динамику развития бизнес-процессов. Сначала хаос, потом регламенты и почта с расшаренным Excel. Потом приходит понимание, что надо что-то большее. Кто-то начинает тратиться на CRM, другие идут со стороны управления задачами.
Для меня интересно было то, что системы начинают все больше интегрироваться и захватывать место в ИТ-структуре предприятия. От ситуации набора разрозненных систем, даже средний бизнес, начинает переходить к интегрированным решениям. Похоже узкое место в когнитивных способностях пользователей, которые не хотят изучать разнообразные системы и хотят получить продукт «все в одном»
Спасибо за интересную статью! Я сейчас наблюдаю данный процесс с другой стороны. А именно — движение от бизнес-процессов в сторону CRM. Мне очень понравилась SaaS-система управления задачами Pyrus и сейчас я помогаю некоторым организациям внедрить её. Там бизнес-процессы организованы в виде многоэтапного согласования задач.
Изначально хотели автоматизировать вспомогательные бизнес-процессы, а потом вошли во вкус и сейчас часть компаний стала создавать импровизированные CRM на базе форм Pyrus.
Получается что это движение обоюдное и пришла пора сквозной интеграции: продажи — бизнес-процессы — производство — учет. И будущее — за интегрированными решениями (или пакетами решений).
Хех… достался мне тут гараж, в котором лет 15 ремонта не было. В итоге крыша течет, полы прогнили. Стал смотреть стоимость ремонта крыши. Крыша шиферная. Часть плит потрескалась. Ценник давали от 12 000 руб. это примерно соответствует полугода арендной платы. Да и аренда земли только до 2016 года. Капитально вкладываться не хочется.
Решение — купить строительный тент 5Х8 м. в Леруа-Мерлен за 566 руб. и прижать его остатками труб и железными уголками из гаража. Profit! При необходимости можно ежегодно менять. Время на замену 30 минут.
Ну с полом пришлось чуть больше повозиться, тут на материал тысячи 3 ушло. Но тоже как новый.
Про гейм-дизайнера логика примерно такая: работал в QA, посмотрел на множество игр которые содержат ошибки. Дальше стал выдвигать предложения по улучшению gameplay потом полностью стал заниматься гейм-дизайном. Фирме лучше взять проверенного человека в гейм-дизайнеры, чем искать с улицы.
Ну дорога наверх и в других областях открыта только тем, кто впахивает и учится. Если совсем не двигаться, то и результаты будут нулевые. И это во всех областях.
Вообще то все не так уж и плохо. Обычно тестировщиков хорошо кормят на работе. Чтобы не отвлекались.
Игры — это весело! Обычно есть возможность выбрать ту игру, которая нравится и создавать такие ситуации от которых у программистов волосы встают дыбом :-)
Плюс потом открыта дорога в гейм-дизайнеры, тим-лиды и т.д.
Так в том то и дело, что в приведенном примере в момент требования доната игровая деятельность прекращается. Соответственно деньги требуются посреди процесса. И в этом суть раздражения автора исходного топика.
Интересно было ознакомиться со статьей. Хорошо что есть общее описание элементов и верхнеуровневая схема сбора пр.
Чего не хватило:
Отличие от других языков описания процессов UML, IDEF0. В каких случаях лучше использовать BPMN? А в каких лучше воздержаться?
Фраза
Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процессаописывает сценарий но не сравнение
Статья говорит о начале моделирования. При этом на выходе хорошо бы получить модель, которую можно применять. А для этого надо на старте понять сколько это может занять времени. Было бы здорово описать верхнеуровнево/ссылочно оценки трудоемкости описания процесса в этой локации. Насколько долго его описывать (возможно от каких то параметров)?
Ну и про завершение. Как понять, что описан именно нужный процесс с учетом того, что реальные бизнес-пользователи с которых снималась модель могут не знать нотификацию?
В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?
Жаль что про ЕГЭ не написал, там столько всего вкусного было )))
Интересно, а почему нельзя окружить кнопку отправки формы графическими элементами с событием «onMouseOver» тогда при переходе на данное поле будет генерироваться событие — которое меняет параметр, говорящий что пользователь — не робот.
Сумма акта в очень порадовала
Посмотрел блок управления задачами, очень сильные упрощения. Сейчас общаюсь по поводу внедрения Pyrus в разных компаниях, многим нужны последовательности процессов и передача документов между стадиями. У вас это непонятно как сделать. Хотя, могу и ошибаться.
Успехов в развитии!
Acronїs — и из нее потом две параллельные прямые вверх могут идти, а из r и ї можно параллельные вниз продолжать
Вдумчивое отношение непрофильного сотрудника к проблеме клиента (как в примере 2) может быть чрезмерной затратой времени сотрудника, при этом он не создаст целевой результат для компании, не получит за это денег.
Мне больше нравится подход — прозрачной переадрессации и невидимых для клиента запросов. Сейчас плотно работаю с Pyrus, поэтому на их примере:
1. Прозрачное перенаправление. Когда пришел запрос, сотрудник переправляет задачу на ответственного за решение, при этом клиент видит кому переправлена задача и как идет по ней ход решения. Все. Это для примера 2.
2. Создание невидимого подзапроса — иногда не надо показывать внутреннюю кухню маршрутизации. Поэтому создается внутренний подзапрос в котором идет разбирательство технической стороны. Клиенту при этом сообщается время ожидания. «Наши специалисты разбираются в ситуации, мы дадим вам ответ в течении ХХХ минут». В случае просрочки — обязательно еще раз связаться с клиентом, извиниться и назвать новый срок.
3. Библиотека стандартных ответов и форм обращения. Из третьего варианта видно, что лучше бы специалистам службы поддержки иметь заготовки вежливых ответов на стандартные вопросы.
Что думаете?
— есть задачи с подзадачами, сколько угодно уровней;
— можно вносить время по каждой задаче;
— для Андроида и других мобильных платформ есть приложения с оффлайн-синхронизацией (залез в подвал, сделал настройки, отметил время, вылез и оно само синхронизуется);
+ можно группировать задачи в проекты и смотреть расход времени по проекту, а так же динамику.
Для меня интересно было то, что системы начинают все больше интегрироваться и захватывать место в ИТ-структуре предприятия. От ситуации набора разрозненных систем, даже средний бизнес, начинает переходить к интегрированным решениям. Похоже узкое место в когнитивных способностях пользователей, которые не хотят изучать разнообразные системы и хотят получить продукт «все в одном»
Изначально хотели автоматизировать вспомогательные бизнес-процессы, а потом вошли во вкус и сейчас часть компаний стала создавать импровизированные CRM на базе форм Pyrus.
Получается что это движение обоюдное и пришла пора сквозной интеграции: продажи — бизнес-процессы — производство — учет. И будущее — за интегрированными решениями (или пакетами решений).
Решение — купить строительный тент 5Х8 м. в Леруа-Мерлен за 566 руб. и прижать его остатками труб и железными уголками из гаража. Profit! При необходимости можно ежегодно менять. Время на замену 30 минут.
Ну с полом пришлось чуть больше повозиться, тут на материал тысячи 3 ушло. Но тоже как новый.
Кроме этого каждое изменение интерфейса — это огромная потеря времени на освоение.
Про гейм-дизайнера логика примерно такая: работал в QA, посмотрел на множество игр которые содержат ошибки. Дальше стал выдвигать предложения по улучшению gameplay потом полностью стал заниматься гейм-дизайном. Фирме лучше взять проверенного человека в гейм-дизайнеры, чем искать с улицы.
Игры — это весело! Обычно есть возможность выбрать ту игру, которая нравится и создавать такие ситуации от которых у программистов волосы встают дыбом :-)
Плюс потом открыта дорога в гейм-дизайнеры, тим-лиды и т.д.