I'm in broad agreement with the concerns raised here, and so I've opened an improvement suggestion so that the discussion can be taken further.
https://projects.tmforum.org/jira/browse/AP-4487 (accessible to project members only). This is the time to remind the community that the Open API project is a collaborative effort, and one of the most effective ways to get things moving is to join the project and contribute!
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: May 19, 2023 03:43
From: Steve Ranford-Bragg
Subject: Appointing API (646)
Ah ok, got it - thanks for clarifying.
I think both of these topics are the sort of thing that a working group George Glass is looking to set up to try to standardise across industry would be very helpful to look at. There are a lot of things beyond the obvious stuff like product model, such as appointing and addressing, which would be very helpful to have standardisation.
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: May 18, 2023 13:03
From: David Whitfield
Subject: Appointing API (646)
Hi @Steve Ranford-Bragg @Derrick Evans , I think we are definitely all talking about the same thing but from different angles.
My original post is focusing on @Derrick Evans further elaboration of "As a reseller of services I am going to place an order or fault with a supplier." from a consumption point of view rather than what I can appreciate is your point of view @Steve Ranford-Bragg for the onward resourcing.
For our angle when you times the number of suppliers that you are taking wholesale services from which have a different perspective on what data points are relevant when essentially filtering their available slots that leads to a very cumbersome API for any client to consume.
That said it comes back to the point that the 646 schema doesnt seem to come close to allowing this form of use case for supplier appointment slots and i've been quite hesitant to consider extension because I though that this surely must be a common scenario in the industry.
@Jonathan Goldberg @Ian Turkington could either of you point in the correct direction of someone who can advise how to use the TMF APIs to solve this issue which we are facing?
thanks
Dave
------------------------------
David Whitfield
TalkTalk Group
Original Message:
Sent: May 18, 2023 09:13
From: Steve Ranford-Bragg
Subject: Appointing API (646)
Hi Derrick,
Completely agree with the appoint use case you mention, one we both know well! :-)
However, I was referring more to the layer underneath that where you create the appointment books and populate them with resources. Again one we both know, but it needs to have a set of employees where it can create a roster pattern of the days and times they are working, have associated skills/resources and be able to populate those into the appointment books. And then when an appointment is booked, block out those times as now unavailable.
The work order API isn't an exact fit, but I adapted it to work although I suspect the intended use is more our engineering pro-active build projects. In that case we build a work pack to specify the defined work items, such as "dig 50m of trench" or "run 200m of cabling" and any associated requirements of skills. That work order can then be passed to internal or external teams to implement.
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: May 18, 2023 08:47
From: Derrick Evans
Subject: Appointing API (646)
Hello All,
I suspect there are a number of things going here where the current API specification does not fit certain use cases.
Reading the narrative in the spec I get the impression that the use case is
As a supplier I have a submitted order or a fault that needs a field technician.
I have access to the appointment books of a number of installer/repairer people.
I find one who is free with the suitable skills at the location.
I make an appointment for that person to go and do the work.
So it feels like an installer or repairer with a list of orders/faults who is scheduling/allocating tasks to named people.
In the use cases I have seen for appointing APIs this is not the process.
Instead for us it is more like
As a reseller of services I am going to place an order or fault with a supplier.
I determine that work will be needed at the customers' premises and that I need to arrange access for a technician on a suitable date.
So I need to negotiate a time with the end user that can be met by the chosen supplier and need to do that at the point of sale/service before submitting the order or fault not after.
I look in the suppliers' appointment books for the availability of an unnamed resource with suitable skills in the location who is potentially rostered to do this type of work (the named people might not actually be allocated until the actual day itself).
Based on that I agree with the end user/customer to provide access on that date and time.
I reserve that appointment.
I follow up that appointment reservation with the order or fault report (referencing the appointment from the order not referencing the order or fault from the appointment).
On the back of the order a fault a work order is created referencing the appointment slot.
On the day or shortly before an algorithm determines the optional allocation of tasks to named people based on skills, location and travelling times between jobs.
I am sure you will both recognise this pattern as it is the one used by at least one wholesale provider of broadband access in the UK.
We too have extensively customised the TMF appointing API to include all sorts of characteristics which are used as the basis for finding a suitable "slot" rather than a named person. And we do not reference the order or fault in the appointment we reference the appointment from the order or fault.
------------------------------
Derrick Evans
BT Group plc
Original Message:
Sent: May 18, 2023 04:20
From: Steve Ranford-Bragg
Subject: Appointing API (646)
Hi David,
I would agree and have been looking at similar problems and have had to make some adaptions to make it work for me too. If I understand correctly, you would seem to be looking at workforce management who you want to assign tasks to but the API seems to be more focused around end user appointments?
We have a very large engineering workforce, both employee and third party, and carry out appointed tasks for end user provision and repair but we also have a large civil pro-active network build function where we want to assign workforce tasks for civil engineering and a way to manage that would be very helpful.
I think possibly that the two might be best separated as different APIs, with a new one specifically for workforce management.
EDIT : I should have checked the early adopter APIs first again - the new work order API is much closer to what we are looking at. I need to look in more detail but does that fit your use case more?
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: May 17, 2023 12:49
From: David Whitfield
Subject: Appointing API (646)
Hi All,
I've been looking at this API recently and it seems to stop someway short of being flexible 'out of the box' for our use case.
I dont know if the use case exists elsewhere around the community but I was trying to understand how 646 could be used to abstract the engineer appointment books of a number of different suppliers. So in essence the application implementing the API doesnt offer timeslots as such to client applications rather it provides a gateway for a consistent interface to do so. Just focusing initially on the searchTimeSlot it appears that the request model is very simple and essentially allows 3 main capabilities: -
1. Specify the timeframe I desire a slot within
2. Indicate a single person/organisation or role associated with the slot
3. Indicate a geographic location
Perhaps it is that the thinking behind the API is that it doesn't fit the use case I have described above but its quite normal for suppliers to divide their workforce resource via its skillset which in turn means them exposing an API where a client need to specify what it is that they want , i.e.
a slot for provision vs assure
a slot for a particular product type
a slot for specific live product (i.e. identifier based)
a slot to service a quantity of products
a slot to include a specific set of work required (specific onsite task)
The 646 schema seems quite inflexible and would require for our use case quite significant extension which before considering this approach I wanted to understand whether: - this is the only real way forward using TMF and therefore valid to do (646 design has never considered such requirements) or this is just totally the wrong TMF API for this set of requirements in which case i'd appreciate some pointers as to what API to look at?
thanks
Dave
------------------------------
David Whitfield
TalkTalk Group
------------------------------