[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Comments on: Status code explanations - IB 17-Aug-11.docxuploaded
|
Hello Johannes Thanks for the detailed review. First, I believe we agreed that an Assignee (user of FFMS) can browse for existing Work Requests, even those that aren't assigned to that Assignee or maybe
not assigned at all – see for example the Asset Management Use Case where an Assignee is already at a site, completed some work ahead of the planned time, and checks whether there is some Periodic Maintenance work planned for any of the other assets at the
site. That work may be planned for 2-3 weeks in the future and not yet assigned to anyone. Still, we want it to be visible to FFMS. This and similar Use Cases are quite frequent in our experience, and therefore I think it is perfectly valid for FFMS to know
about work that has not been assigned yet. Just one more example: When an Assignee reaches a customer location, the customer may already know there is more work planned for a week or month in the future. That work may not be assigned yet, but it would be strange
if the Assignee didn't know about it and couldn't find any info about it. Regarding re-assignment from one Assignee to another: I believe it is much more useful to keep the same Work Request rather than cancel it and create a new
one linked to the same task. Two reasons: First, in an environment where there's a lot of dynamic change (new urgent tasks, delays, workforce absences, …), the schedule is updated at a high rate: Work Requests are moved to different times and different Assignees.
If each such re-assignment creates a cancellation and a new WR, this will lead to a large number of WRs that don't have much semantic meaning (why should I care that some WR that should be done at 4PM has been re-assigned three times since 8AM?), and it will
make it harder to read the work history and to do meaningful analytics. How much clutter could be generated? Think of delivering and installing a switchboard for a large office. It could cover dozens of Tasks over a week or more, performed by 5-10 people.
If each of these Tasks gets re-assigned only once, we will have many cancelled WRs and new WRs. Furthermore, the cancelled WRs will include some history, since each of them will reflect some progress in the overall execution before the WR was cancelled due
to one more re-scheduling. Second, if ERMS has one set of objects (Tasks) and FFMS has another set of objects (WRs), we need a mapping between them so that ERMS can convey progress status to its own users. That is fine, in my opinion but the mapping should
not be cluttered and complicated with useless information about how the Task has gone through several different mappings to different WRs, just because of re-assignments.
You say "when the work is split to multiple Tasks assigned to different Assignees, then a separate Work Request must be created for each of them".
However, my understanding of the definitions was that while an Activity has one Assignee, the set of Activities related to one WR or one Task may include several Assignees. I have now gone back to the definitions and I see "Task refers to a well-specified
group of Activities performed by an Assignee. Activities can be performed in sequence or parallel, and they may have dependencies on each other.", which does not match my memory
of our discussions, but I would argue that this should really be "Task refers to a well-specified group of Activities performed by one or more Assignees": while it does
happen that Activities are performed in parallel by one Assignee, that's not a very common case, so if we allow "in parallel" we should be talking about several Activities belonging to the same Task, performed by different Assignees. Alternatively, if we require
that all Activities in the same Task must have the same Assignee, I think the additional hierarchy level of Steps is less useful.
All of the above, in my opinion, leads to the conclusion that on the one hand, as you said, there can't be a perfect 1:1 mapping between ERMS work description
and FFMS work description. On the other hand, I believe that we can design the model so that most cases do lead to a simple 1:1 mapping, leaving other mapping to special cases and exceptions. Lastly, regarding the transition diagram: As I wrote, it is intended as an illustrative example only of one possible diagram. That example is not mandatory.
The Manager will specify at least one transition diagram and possibly a large number of such diagrams, following the specification (e.g. with some or all WRs having their own diagram, while other WRs share diagrams which exist in the catalog).
Best regards, Israel Beniaminy Senior VP, Product Strategy ClickSoftware Technologies Ltd. (http://www.clicksoftware.com) Office phone: +972 3 7659475; Mobile: +972 54 6722475 Azorim Park, Oren Building 94 Em-Hamoshavot Road Petach-Tikva 49527, Israel From: Johannes Lehtinen [mailto:johannes.lehtinen@rossum.fi]
Hi! Thank you for the explanations, this helped me to understand how you were envisioning to use the different status codes. 2011/8/17 <israel.beniaminy@clicksoftware.com> The document named Status code explanations - IB 17-Aug-11.docx has been
CONFIDENTIALITY NOTICE: This email may contain ClickSoftware confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by email and delete the message and any file attachments from your computer. Thank you. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]