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