Как таск-треккеры несколько лет использовал Pyrus и YouGile - оба предоставляют сервисы как для личного использования, так и для небольших команд. Что приятно бесплатно. Быстрый ввод задач (в Pyrus прямо из почты можно форвардом задачи создавать), хорошие мобильные приложения, канбан-представления. Странно что они и Kaiten вне поле зрения.
Проблема в том, что меры писались изначально для аэропортов, а потом были распространены на все транспортные предприятия. При этом куча мер выполняется формально.
У Pyrus несколько другая модель лицензирования. Там если только задачами управлять, то на бесплатном тарифе может быть неограниченное количество пользователей. Ограничение будет в месте хранения. Подробности в https://pyrus.com/ru/pricing
Любопытный взгляд на риски при разработке игр. Внесу несколько дополнений. 1. Если рассматривать сертификации, то вместо САМР возможно стоит рассмотреть IPMA, который более распространен в России. 2. Почему то за бортом остались все риски проектирования: - реализованный объем фич не дает нужного эффекта, - забагованность кода, когда фичи вроде реализованы, но потом возвращаются бумерангом, - потеря компетентных исполнителей (отчасти это учитывается в выгорании, но возможны и другие причины) - ошибки интеграции с другими командами. 3. Автор обладает большим опытом работы, который позволяет выделить главные аспекты и при этом многие вещи кажутся очевидными и проходят мимо повествования. Например, полезно рассмотреть модель риска, которая состоит из, ФАКТОРОВ, которые приводят к возникновению СОБЫТИЯ, которое влечет ПОСЛЕДСТВИЯ, для проекта.
При этом примеры риск-индикаторов здесь - это формализация ПОСЛЕДСТВИЙ, а для системной работы нужно спускаться в анализ СОБЫТИЙ и ФАКТОРОВ. Автор упоминает это походя, но тут то и кроются основные моменты работы с рисками (прогнозирование, резервирование, предотвращение).
Именно для канбан-досок (задачи + списки/доски) Pyrus можно вообще бесплатно использовать. Плата понадобится для автоматизации бизнес-процессов (формы, маршрутизация).
Интересно было ознакомиться со статьей. Хорошо что есть общее описание элементов и верхнеуровневая схема сбора пр. Чего не хватило:
Отличие от других языков описания процессов 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 ушло. Но тоже как новый.
Как таск-треккеры несколько лет использовал Pyrus и YouGile - оба предоставляют сервисы как для личного использования, так и для небольших команд. Что приятно бесплатно. Быстрый ввод задач (в Pyrus прямо из почты можно форвардом задачи создавать), хорошие мобильные приложения, канбан-представления. Странно что они и Kaiten вне поле зрения.
Проблема в том, что меры писались изначально для аэропортов, а потом были распространены на все транспортные предприятия. При этом куча мер выполняется формально.
У Pyrus несколько другая модель лицензирования. Там если только задачами управлять, то на бесплатном тарифе может быть неограниченное количество пользователей. Ограничение будет в месте хранения. Подробности в https://pyrus.com/ru/pricing
Любопытный взгляд на риски при разработке игр. Внесу несколько дополнений.
1. Если рассматривать сертификации, то вместо САМР возможно стоит рассмотреть IPMA, который более распространен в России.
2. Почему то за бортом остались все риски проектирования:
- реализованный объем фич не дает нужного эффекта,
- забагованность кода, когда фичи вроде реализованы, но потом возвращаются бумерангом,
- потеря компетентных исполнителей (отчасти это учитывается в выгорании, но возможны и другие причины)
- ошибки интеграции с другими командами.
3. Автор обладает большим опытом работы, который позволяет выделить главные аспекты и при этом многие вещи кажутся очевидными и проходят мимо повествования. Например, полезно рассмотреть модель риска, которая состоит из,
ФАКТОРОВ, которые приводят к возникновению
СОБЫТИЯ, которое влечет
ПОСЛЕДСТВИЯ, для проекта.
При этом примеры риск-индикаторов здесь - это формализация ПОСЛЕДСТВИЙ, а для системной работы нужно спускаться в анализ СОБЫТИЙ и ФАКТОРОВ. Автор упоминает это походя, но тут то и кроются основные моменты работы с рисками (прогнозирование, резервирование, предотвращение).
Именно для канбан-досок (задачи + списки/доски) Pyrus можно вообще бесплатно использовать. Плата понадобится для автоматизации бизнес-процессов (формы, маршрутизация).
Интересно было ознакомиться со статьей. Хорошо что есть общее описание элементов и верхнеуровневая схема сбора пр.
Чего не хватило:
Отличие от других языков описания процессов UML, IDEF0. В каких случаях лучше использовать BPMN? А в каких лучше воздержаться?
Фраза
Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процессаописывает сценарий но не сравнение
Статья говорит о начале моделирования. При этом на выходе хорошо бы получить модель, которую можно применять. А для этого надо на старте понять сколько это может занять времени. Было бы здорово описать верхнеуровнево/ссылочно оценки трудоемкости описания процесса в этой локации. Насколько долго его описывать (возможно от каких то параметров)?
Ну и про завершение. Как понять, что описан именно нужный процесс с учетом того, что реальные бизнес-пользователи с которых снималась модель могут не знать нотификацию?
В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?
Жаль что про ЕГЭ не написал, там столько всего вкусного было )))
Интересно, а почему нельзя окружить кнопку отправки формы графическими элементами с событием «onMouseOver» тогда при переходе на данное поле будет генерироваться событие — которое меняет параметр, говорящий что пользователь — не робот.
Сумма акта в очень порадовала
Посмотрел блок управления задачами, очень сильные упрощения. Сейчас общаюсь по поводу внедрения Pyrus в разных компаниях, многим нужны последовательности процессов и передача документов между стадиями. У вас это непонятно как сделать. Хотя, могу и ошибаться.
Успехов в развитии!
Acronїs — и из нее потом две параллельные прямые вверх могут идти, а из r и ї можно параллельные вниз продолжать
Вдумчивое отношение непрофильного сотрудника к проблеме клиента (как в примере 2) может быть чрезмерной затратой времени сотрудника, при этом он не создаст целевой результат для компании, не получит за это денег.
Мне больше нравится подход — прозрачной переадрессации и невидимых для клиента запросов. Сейчас плотно работаю с Pyrus, поэтому на их примере:
1. Прозрачное перенаправление. Когда пришел запрос, сотрудник переправляет задачу на ответственного за решение, при этом клиент видит кому переправлена задача и как идет по ней ход решения. Все. Это для примера 2.
2. Создание невидимого подзапроса — иногда не надо показывать внутреннюю кухню маршрутизации. Поэтому создается внутренний подзапрос в котором идет разбирательство технической стороны. Клиенту при этом сообщается время ожидания. «Наши специалисты разбираются в ситуации, мы дадим вам ответ в течении ХХХ минут». В случае просрочки — обязательно еще раз связаться с клиентом, извиниться и назвать новый срок.
3. Библиотека стандартных ответов и форм обращения. Из третьего варианта видно, что лучше бы специалистам службы поддержки иметь заготовки вежливых ответов на стандартные вопросы.
Что думаете?
— есть задачи с подзадачами, сколько угодно уровней;
— можно вносить время по каждой задаче;
— для Андроида и других мобильных платформ есть приложения с оффлайн-синхронизацией (залез в подвал, сделал настройки, отметил время, вылез и оно само синхронизуется);
+ можно группировать задачи в проекты и смотреть расход времени по проекту, а так же динамику.
Для меня интересно было то, что системы начинают все больше интегрироваться и захватывать место в ИТ-структуре предприятия. От ситуации набора разрозненных систем, даже средний бизнес, начинает переходить к интегрированным решениям. Похоже узкое место в когнитивных способностях пользователей, которые не хотят изучать разнообразные системы и хотят получить продукт «все в одном»
Изначально хотели автоматизировать вспомогательные бизнес-процессы, а потом вошли во вкус и сейчас часть компаний стала создавать импровизированные CRM на базе форм Pyrus.
Получается что это движение обоюдное и пришла пора сквозной интеграции: продажи — бизнес-процессы — производство — учет. И будущее — за интегрированными решениями (или пакетами решений).
Решение — купить строительный тент 5Х8 м. в Леруа-Мерлен за 566 руб. и прижать его остатками труб и железными уголками из гаража. Profit! При необходимости можно ежегодно менять. Время на замену 30 минут.
Ну с полом пришлось чуть больше повозиться, тут на материал тысячи 3 ушло. Но тоже как новый.