Imagine that I have the following customer journey:
1 - Customer requests an Internet Service
2 - Salesman requests an Address which the service will be installed
3 - Salesman inputs that Address (zip code and number or part of street code) in a CRM system and choose the Customer Address
4 - Based on that Address and informed address complement the CRM have to call a API to get the technical address in the outside plant inventory, because based on that address that will be possible to check service and resource availability.
Therefore, I'm always having to handle Customer Address and Technical Address. What are the best practices in that case? Should I have one single Location Management base. In consequence of this, when I'm planning and registering a new outside side plant resource, I have to consult that location management system? Also, the outside plant maps are design and register by the engineering team, which means that they are out of scale, so that system has their own map and their own locations and address list.
#CustomerExperience#DigitalEcosystems#OpenDigitalArchitecture#General------------------------------Caui LealTelefonica Brasil S.A.------------------------------
I do not know if I was clear. Just to give a little bit of context. Currently ours Outside plant Resource Inventories (2) have their own location management system internal in the application. However, to support billing address and customer address we have other location management system. Therefore, I'm looking a way to simplify that architecture, does TM Forum has any document that can drive Location Management best practises and a reference architecture?
TMF Open APIs has various APIs in the field of address management - TMF673 (address), 674 (site), 675 (location). But the Open API project makes no statement about software architecture, or how addresses are used. So you could expose these APIs from both your location management systems, you would need to ensure that the consumer invokes the correct endpoint according to where it is in the process.
TMF ODA already talks about a Location Management component, and rather controversially has placed that component into the Production area (which would actually match your internal location system). But when dealing with addresses such as billing, shipping, etc. you would think that the address management belongs in the Party area.
The problem that I'm trying to solve is exactly that one that you mention: dealing with multiplus address, because in some cases we need a orchestration to get "Customer Address", geocoding it and get "Technical Address" (Address in outside plant inventories). However, as far as I understood it shouldn't be a problem.