Pull to refresh
9
0
vorobyev @vorobyev

User

Интересно было ознакомиться со статьей. Хорошо что есть общее описание элементов и верхнеуровневая схема сбора пр.
Чего не хватило:

  1. Отличие от других языков описания процессов UML, IDEF0. В каких случаях лучше использовать BPMN? А в каких лучше воздержаться?
    Фраза
    Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процесса
    описывает сценарий но не сравнение

  1. Статья говорит о начале моделирования. При этом на выходе хорошо бы получить модель, которую можно применять. А для этого надо на старте понять сколько это может занять времени. Было бы здорово описать верхнеуровнево/ссылочно оценки трудоемкости описания процесса в этой локации. Насколько долго его описывать (возможно от каких то параметров)?

  2. Ну и про завершение. Как понять, что описан именно нужный процесс с учетом того, что реальные бизнес-пользователи с которых снималась модель могут не знать нотификацию?
    В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?

Ого: сколько всего уже сделано! SStrelkov поздравляю!
Жаль что про ЕГЭ не написал, там столько всего вкусного было )))
Ну так дальше все просто — заходим в AppStore/GooglePlay и ставим приложению одну звезду за надоедающие всплывающие окна. Как только это станет массовым, то приложение начинает сильно терять рейтинг и тратить больше на рекламу. В какой-то момент система придет к равновесию и исключит ненужные уведомления.
Все, накрылся сайтик… видать массово народ пошел тестировать :)
Наивный вопрос.
Интересно, а почему нельзя окружить кнопку отправки формы графическими элементами с событием «onMouseOver» тогда при переходе на данное поле будет генерироваться событие — которое меняет параметр, говорящий что пользователь — не робот.
Ну и опять же тестерское прошлое не вывести. :-)
Сумма акта в
6236.88683494636
очень порадовала
Посмотрел, любопытно. Похоже заточено скорее на торговую деятельность. Закупку, продажу со склада. Хорошо, если получится быть дешевле и удобнее 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 потом полностью стал заниматься гейм-дизайном. Фирме лучше взять проверенного человека в гейм-дизайнеры, чем искать с улицы.
Ну дорога наверх и в других областях открыта только тем, кто впахивает и учится. Если совсем не двигаться, то и результаты будут нулевые. И это во всех областях.
Вообще то все не так уж и плохо. Обычно тестировщиков хорошо кормят на работе. Чтобы не отвлекались.
Игры — это весело! Обычно есть возможность выбрать ту игру, которая нравится и создавать такие ситуации от которых у программистов волосы встают дыбом :-)
Плюс потом открыта дорога в гейм-дизайнеры, тим-лиды и т.д.
Так в том то и дело, что в приведенном примере в момент требования доната игровая деятельность прекращается. Соответственно деньги требуются посреди процесса. И в этом суть раздражения автора исходного топика.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity

Specialization

Quality Assurance Manager, Project Manager
Middle
Project management
Organization of business processes
Optimization of business processes
Automation of processes