Бизнес-логика: кто закрывает задачу
исполнитель закрывает условно, типа по его мнению все сделано, а заказчик закрывает окончательно, типа согласен
не аргументировано:)
я приведу свой аргумент в пользу закрывания исполнителем:
заказчика, получившего свое, сложнее заставить ходить и подписывать "закрытие", чем подписать исполнителю (экономия времени). В закрытии заинтересован все-таки исполнитель.
Примечание: можно всегда оставить заказчику право "открыть заново". Если исполнитель закрыл задачу, она считается закрытой. заказчику можно послать уведомление.
но я боюсь что-нибудь не учесть.
какие минусы в таком варианте?
я приведу свой аргумент в пользу закрывания исполнителем:
заказчика, получившего свое, сложнее заставить ходить и подписывать "закрытие", чем подписать исполнителю (экономия времени). В закрытии заинтересован все-таки исполнитель.
Примечание: можно всегда оставить заказчику право "открыть заново". Если исполнитель закрыл задачу, она считается закрытой. заказчику можно послать уведомление.
но я боюсь что-нибудь не учесть.
какие минусы в таком варианте?
заказчику надо результат
исполнителю надо денег
в твоем случае, после чего исполнитель получает деньги?
поставили мне задачу, я сам ее закрыл и сам получил деньги :]
исполнителю надо денег
в твоем случае, после чего исполнитель получает деньги?
поставили мне задачу, я сам ее закрыл и сам получил деньги :]
не, я писала, вопрос оплаты не учитывается.
пусть это сервисное гарантийное обслуживание,
жест доброй воли и все что угодно.
но деньги платятся НЕ единовременно за закрытие.
исполнитель просто заинтересован, чтобы задача была закрыта.
если "сам закрыл" - не решив,
то заказчик тут же ее откроет заново, т.к. он заинтересован в решении задачи
пусть это сервисное гарантийное обслуживание,
жест доброй воли и все что угодно.
но деньги платятся НЕ единовременно за закрытие.
исполнитель просто заинтересован, чтобы задача была закрыта.
если "сам закрыл" - не решив,
то заказчик тут же ее откроет заново, т.к. он заинтересован в решении задачи
за сервисное гарантийное обслуживание деньги платят, только платит не заказчик, а третье лицо
а если это жест доброй воли, то ничего закрывать не надо и так есть мотивация чтобы все сделать
а если это жест доброй воли, то ничего закрывать не надо и так есть мотивация чтобы все сделать
то, что ты предлагаешь это колхоз, все общее и никто ни за что не отвечает
я так понимаю, что задача не абстрактна, опиши конкретный процесс
я так понимаю, что задача не абстрактна, опиши конкретный процесс
Заказчик/клиент НИКОГДА не должен участвовать в бизнес-процессе как исполнитель задач. Он НИКОГДА не закрывает и не открывает задачи и не ставит отметки. Он вообще понятия не имеет о бизнес-процессах компании. Стало быть в бизнес-процессе могут участвовать ТОЛЬКО представители компании (продающей сникерсы 
).
2. В данном конкретном примере на каком-то шаге сотруднику фирмы ставится задача: "Доставить сникерсы заказчику". Сотрудник едет к заказчику и отдает коробку, взамен он получает подписанный акт сдачи-приемки. Всё! Сотрудник приезжает в офис и закрывает задачу, например, указав номер и дату подписанного акта сдачи-приемки.
3. Если нужно проконтролировать работу сотрудника, то после задачи "Доставить бла-бла..." может быть предусмотрен отдельный шаг бизнес-процесса "Проконтролировать бла-бла...", на котором задача идет, например, менеджеру отдела доставки. Он, получив эту задачу, идет и проверяет, что акт сдачи-приемки правильно оформлен и подписан клиентом. Если всё в порядке, менеджер ставит в задаче отметку и закрывает её. На этом бизнес-процесс завершается.
).2. В данном конкретном примере на каком-то шаге сотруднику фирмы ставится задача: "Доставить сникерсы заказчику". Сотрудник едет к заказчику и отдает коробку, взамен он получает подписанный акт сдачи-приемки. Всё! Сотрудник приезжает в офис и закрывает задачу, например, указав номер и дату подписанного акта сдачи-приемки.
3. Если нужно проконтролировать работу сотрудника, то после задачи "Доставить бла-бла..." может быть предусмотрен отдельный шаг бизнес-процесса "Проконтролировать бла-бла...", на котором задача идет, например, менеджеру отдела доставки. Он, получив эту задачу, идет и проверяет, что акт сдачи-приемки правильно оформлен и подписан клиентом. Если всё в порядке, менеджер ставит в задаче отметку и закрывает её. На этом бизнес-процесс завершается.
исполнитель отвечает за свою задачу.
заказчику обеспечивается возможность в любой момент открыть заново,
и он уведомляется о закрытии задачи.
Нужно ли тратить время исполнителя, заставляя его бегать за заказчиком, чтобы тот подписал исполнение? Какие плюсы мы сможем получить прии такой жертве?
п.с. процессов довольно много. а данной ситуации и заказчики и исполнители находятся в рамках одной организации, исполнители отвечают перед свои начальством за удовлетворение заказчиков, заказчики ведут свои работы, используя в качестве ресурсов результаты исполнителей. Мне нужно определить некие общие принципы оптимизации бизнеса.
заказчику обеспечивается возможность в любой момент открыть заново,
и он уведомляется о закрытии задачи.
Нужно ли тратить время исполнителя, заставляя его бегать за заказчиком, чтобы тот подписал исполнение? Какие плюсы мы сможем получить прии такой жертве?
п.с. процессов довольно много. а данной ситуации и заказчики и исполнители находятся в рамках одной организации, исполнители отвечают перед свои начальством за удовлетворение заказчиков, заказчики ведут свои работы, используя в качестве ресурсов результаты исполнителей. Мне нужно определить некие общие принципы оптимизации бизнеса.
а данной ситуации и заказчики и исполнители находятся в рамках одной организацииБлин, с этого и надо было начинать, а то сникерсы, сникерсы...
. Заказчик/клиент НИКОГДА не должен участвовать в бизнес-процессе как исполнитель задач. Он НИКОГДА не закрывает и не открывает задачи и не ставит отметки. Он вообще понятия не имеет о бизнес-процессах компании. Стало быть в бизнес-процессе могут участвовать ТОЛЬКО представители компании (продающей сникерсы). .в рамках межкорпоративных процессах очень разумный аргумент. к сожалению, мне сейчас интересна ситуация только при наличии общекорпоративного процесса, в котором вполне реально задействовать всех.
.тут рассматривается задача не сотруднику от руководства, а задача фирме - поставщику сникерсов. Ставит ее все же заказчик. В твоем примере акт сдачи-приемки подписывается и заказчиком. Нужно ли это?
2. В данном конкретном примере на каком-то шаге сотруднику фирмы ставится задача: "Доставить сникерсы заказчику". Сотрудник едет к заказчику и отдает коробку, взамен он получает подписанный акт сдачи-приемки. Всё! Сотрудник приезжает в офис и закрывает задачу, например, указав номер и дату подписанного акта сдачи-приемки..
.задача контроля интересна, но опять же рамках отношений заказчик-исполнитель контроль выполняет сначаоа исполнитель, потом заказчик. Но нужно ли, чтобы он по умолчанию он был НЕ СОГЛАСЕН? (пока не поставит подпись на акте)
3. Если нужно проконтролировать работу сотрудника, то после задачи "Доставить бла-бла..." может быть предусмотрен отдельный шаг бизнес процесса "Проконтролировать бла-бла...", на котором задача идет, например, менеджеру отдела доставки. Он, получив эту задачу, идет и проверяет, что акт сдачи-приемки правильно оформлен и подписан клиентом. Если всё в порядке, менеджер ставит в задаче отметку и закрывает её. На этом бизнес-процесс завершается.
откройте позицию "разносчика папок"
он и будет бегать за заказчиками и собирать подписи.
он и будет бегать за заказчиками и собирать подписи.
тогда количество штатных единиц удвоится (а как известно низкооплачиваемых специалистов еще и трудно удерживать)
процессов - море
это 70% процентов компании будет секретарями, если вести политику "есть секретари" - "можно фиксировать и подписывать каждый чих"
процессов - море
это 70% процентов компании будет секретарями, если вести политику "есть секретари" - "можно фиксировать и подписывать каждый чих"
я предлагаю контраргументы, потому что мне хочу увидеть развитие решений)
а так спасибо большое всем ответившим, потому что мне очень интересны альтернативные варианты
а так спасибо большое всем ответившим, потому что мне очень интересны альтернативные варианты
тут рассматривается задача не сотруднику от руководства, а задача фирме - поставщику сникерсов. Ставит ее все же заказчик. В твоем примере акт сдачи-приемки подписывается и заказчиком. Нужно ли это?Если говорить о бизнес-процессе по продаже сникерсов, а не о внутрикорпоративном БП, то этот БП относится к категории т.н. ПЕРВИЧНЫХ бизнес-процессов, то есть таких БП, которые направлены на непосредстввенное удовлетворение потребностей ВНЕШНИХ клиентов. Внешние клиенты НИКОГДА не участвуют в таких БП в качестве исполнителей задач. Они даже не запускают эти БП. Они могут только оставить заказ (по телефону, факсу, мылу или через сайт, например). Сотрудник, принимающий заказ (напр, по телефону) стартует нужный бизнес-процесс, и после этого задача приходит к исполнителю.
В случае внутрикорпоративных БП все, конечно, делается подругому.
ну какая по сути разница?
назовем бизнес-процессом отношение из 2 лиц: заказчика и исполнителя.
клиент=заказчик
поставщик=исполнитель
между ними процесс
оплату не рассматриваем
и все. не важно внунтренний он или внешний
назовем бизнес-процессом отношение из 2 лиц: заказчика и исполнителя.
клиент=заказчик
поставщик=исполнитель
между ними процесс
оплату не рассматриваем
и все. не важно внунтренний он или внешний
Теперь о внутрикорпоративных БП:
1. Сотрудник ОП (Иванов обнаруживший баг, запускает данный БП, указав описание ошибки
2. БП после своего старта создает задачу для начальника ИТ (Начальник который должен назначить исполнителя. Начальник, получив эту задачу назначает исполнителя и закрывает эту задачу.
3. БП формирует задачу назначенному исполнителю (Петров). Петров, получив задачу, исправляет баг (так ему кажется) и закрывает задачу.
4. БП формирует задачу Иванову, который зпустил этот процесс, чтобы тот подтвердил исправление бага. Иванов проверяет и обнаруживает, что баг нихрена не исправлен и что Петров облажался. Иванов в негоодовании ставит в своей задаче пометку "НЕ ПОДТВЕРЖДЕНО" и закрывает задачу.
5. БП возвращается на шаг 3 и формирует Петрову еще одну задачу. Если надо, БП может отправить Начальнику ИТ нотифай о том, что дескать ваш Петров облажался
6. Ну и так до тех пор, пока Иванов не подтвердит исправление бага.
З.Ы. Нужно понять, что задачи, которые закрыты, не принято переоткрывать. Так бизнес-процессы никто не пишет
исполнители отвечают перед свои начальством за удовлетворение заказчиков, заказчики ведут свои работы, используя в качестве ресурсов результаты исполнителей. Мне нужно определить некие общие принципы оптимизации бизнеса.Ну это довольно стандартная ситуация. Возьмем такой пример. В компании есть отдел продаж (ОП сотрудники которого пользуются корпоративной базой данных, и отдел ай-ти (ИТ который эту базу данных сопровождает и поддерживает. Есть бизнес-процесс исправления багов в этой базе данных. Такой бизнес-процесс мог бы выглядеть так:
1. Сотрудник ОП (Иванов обнаруживший баг, запускает данный БП, указав описание ошибки
2. БП после своего старта создает задачу для начальника ИТ (Начальник который должен назначить исполнителя. Начальник, получив эту задачу назначает исполнителя и закрывает эту задачу.
3. БП формирует задачу назначенному исполнителю (Петров). Петров, получив задачу, исправляет баг (так ему кажется) и закрывает задачу.
4. БП формирует задачу Иванову, который зпустил этот процесс, чтобы тот подтвердил исправление бага. Иванов проверяет и обнаруживает, что баг нихрена не исправлен и что Петров облажался. Иванов в негоодовании ставит в своей задаче пометку "НЕ ПОДТВЕРЖДЕНО" и закрывает задачу.
5. БП возвращается на шаг 3 и формирует Петрову еще одну задачу. Если надо, БП может отправить Начальнику ИТ нотифай о том, что дескать ваш Петров облажался
6. Ну и так до тех пор, пока Иванов не подтвердит исправление бага.
З.Ы. Нужно понять, что задачи, которые закрыты, не принято переоткрывать. Так бизнес-процессы никто не пишет
ну блиииин.
Во-первых, мне не важна детализация пошаговая.
Важно что: у тебя Иванов по дефолту НЕ СОГЛАСЕН что баг исправлен. и пока он не подтвердит, баг считается неисправленным.
А что если сделать наоборот - если петров сказал "исправлен", то баз считается исправленным.
если иванов получил нотифай и ему не понравился результат - вот тогда пусть откроет заново. и так далее.
Во-первых, мне не важна детализация пошаговая.
Важно что: у тебя Иванов по дефолту НЕ СОГЛАСЕН что баг исправлен. и пока он не подтвердит, баг считается неисправленным.
А что если сделать наоборот - если петров сказал "исправлен", то баз считается исправленным.
если иванов получил нотифай и ему не понравился результат - вот тогда пусть откроет заново. и так далее.
с точки зрения фиксации факта исполнения и его последующего доказывания есть различные правила поставки, сдачи-приемки и т.п.
к примеру, ИНКОТЕРМС, национальные методические рекомендации, можно и самим разработать правила взаимодействия по этому поводу - лишь бы ГК не нарушали.
к примеру, ИНКОТЕРМС, национальные методические рекомендации, можно и самим разработать правила взаимодействия по этому поводу - лишь бы ГК не нарушали.
у тебя Иванов по дефолту НЕ СОГЛАСЕН что баг исправлен. и пока он не подтвердит, баг считается неисправленным.Что значит "пусть откроет заново"? И что значит "по дефолту не согласен"? Иванову приходит задача подтвердить/не подтвердить. Он выбирает поставить отметку о подтверждлении или не поставить. После этого выолняет свою задачу. Дальше БП идет туда или сюда в зависимости от ответа Иванова на предыдущем шаге.
А что если сделать наоборот - если петров сказал "исправлен", то баз считается исправленным.
если иванов получил нотифай и ему не понравился результат - вот тогда пусть откроет заново. и так далее.
Кроме того, по-хорошему баг нельзя считать исправленным до тех пор, пока не завершится БП, "посвященный" этому багу. Т.ч. фраза "если петров сказал "исправлен", то баз считается исправленным" мне кажется некорректной.
о, спасибо.
а еще кроме инкотермс есть хорошие регламентные рекомендации?
а еще кроме инкотермс есть хорошие регламентные рекомендации?
почему нельзя завершить БП на петрове.
а последующее вмешательство иванова объявить исключением и для таких случаев описать открытие нового процесса "доработка".
а последующее вмешательство иванова объявить исключением и для таких случаев описать открытие нового процесса "доработка".
это была я=)
все зависит от специфики ситуации - можно, конечно, и содрать, но подойдет ли?
з.ы.: в гаранте или консультанте есть - ищи что-то типа "правила сдачи-приемки работ/ товара", "правили перевозки" и т.п.
обычно они в форме Методических рекомендаций издаются соответствующим федеральным органом исполнительной власти. но, скорее всего, это будут советского времени акты - ведь щас ГК говорит - делайте, че хотите, только мои императивы не нарушайте.
а так, можно их переделать, как любят экономисты, и в пошаговой манере. для работ лучше сетевые графики взять за основу - понятно, что старо, но зато эффективно можно поставить под контроль процесс выполнения - ускорить его. да много че можно, если озадачиться
з.ы.: в гаранте или консультанте есть - ищи что-то типа "правила сдачи-приемки работ/ товара", "правили перевозки" и т.п.
обычно они в форме Методических рекомендаций издаются соответствующим федеральным органом исполнительной власти. но, скорее всего, это будут советского времени акты - ведь щас ГК говорит - делайте, че хотите, только мои императивы не нарушайте.
а так, можно их переделать, как любят экономисты, и в пошаговой манере. для работ лучше сетевые графики взять за основу - понятно, что старо, но зато эффективно можно поставить под контроль процесс выполнения - ускорить его. да много че можно, если озадачиться
а последующее вмешательство иванова объявить исключением и для таких случаев описать открытие нового процесса "доработка".Можно, конечно. И такой подход довольно распространен. Но его, как мне кажется, нужно использовать осторожно. В данном примере (про баги) лично я бы не стал, создавать два БП, если тех же целей можно добиться одним. Аргументов здесь два: первый — в едином БП не такая уж сложная структура, чтобы его разбивать на два; второй — один БП на один баг выглядит логичнее и проще, типа нашли баг — запустили БП, исправили баг (окончательно) — БП завершился. Разбивать на два (в стиле работка/доработка
имхо, имеет смысл, например, если структура единого БП становится очень сложной. Пример:Есть БП "сделать то-то". Запускают его сотрудники отдела А. Основную часть работы в этом БП выполняют сотрудники отделов Б и В. И там и там к этому БП привлекается много народу в довольно нетривиальной последовательности, и согласно весьма ветвистой и сложной логике. Если, допустим, отдел А окажется недовольным работой отделов Б и В, и "реакция" на такое недовольство должна быть тоже весьма непростой (напр., в этом случае должны привлекаться предствители высшего руководства компании, нужны специальные процедуры по разбирательтву, должны полететь головы виновных и т.д. и т.п. то имеет смысл описать ОТДЕЛЬНЫЙ БП, который реализовал бы все эти малоприятные процедуры.
ну сейчас есть современные системы, позволяющие проводить БП электронно и задавать полностью маршруты, права доступа, экранчики и все-все-все...
моя цель - не нарисовать какой-нибудь процессик по каким-нибудь нормативам,
а в каждом конкрентном случае оптимизировать модель
урезать все лишние итерации
распараллельить по максимуму
предусмотреть все возможные варианты развития (процесс должен быть устойчивым к ошибкам и изменениям)
поэтому и встал вопрос - насколько критично урезать итерацию "закрытие заказчиком"
моя цель - не нарисовать какой-нибудь процессик по каким-нибудь нормативам,
а в каждом конкрентном случае оптимизировать модель
урезать все лишние итерации
распараллельить по максимуму
предусмотреть все возможные варианты развития (процесс должен быть устойчивым к ошибкам и изменениям)
поэтому и встал вопрос - насколько критично урезать итерацию "закрытие заказчиком"
ну идею я в общем поняла..)
но можно даже не робить на 2 процесса, просто сделать допустимым развитие процесса по маршруту "открыть заново-доработать", а можно сделать допустимой остановку маршрута на этапе "закрыто исполнителем".
но можно даже не робить на 2 процесса, просто сделать допустимым развитие процесса по маршруту "открыть заново-доработать", а можно сделать допустимой остановку маршрута на этапе "закрыто исполнителем".
просто сделать допустимым развитие процесса по маршруту "открыть заново-доработать"Зачем отдельный маршрут? Итерация подходит гораздо лучше. Тем более что итераций может быть много.
Есть еще такой вариант, который довольно часто используется: ставим форк, в одной ветке даем задачу исполнителю "сделать то-то", в параллельной ветке даем задачу заказчику "принять сделанное", замыкаем обе ветки джойном. Но все-таки итерация выглядит логичнее.
196papik
если имеется бизнес-процесс (совершенно любой, хоть покупка коробки сникерсов для девушекимеется заказчик и исполнитель.
понятно, что каждую новую задачу между ними инициирует заказчик.
Вопрос:
кто должен закрывать задачу (ставить отметку об исполнении) - заказчик или исполнитель?
какие плюсы и минусы в каждом из случаев?