Do your customers understand how to get service from your organization?

Do your customers understand what to expect from the services you deliver?

Are your customers frustrated and upset when they interact with your Service Desk?

Recently, I was on the customer end of service delivery. It got me thinking about what we could do better in order to deliver quality customer service.  Here is my tale:

My doctor wrote an order for me to get some x-rays.  I arrived at the radiology lab and took a number and waited to be called. After a short period, the receptionist called my number, took my details and asked me wait for my x-ray. There were about 20 people in the waiting area.  As time went by, all the people in the waiting area who were there when I arrived were called in as well as a group of people who arrived after me.  I waited patiently for 30 minutes, then 45 minutes getting more and more agitated. I felt like I was not being treated fairly and that made me angry. Finally, when someone arrived 50 minutes after me and was called in for their procedure, I approached the receptionist and asked if they forgot me. The answer I got blew me away …

No sir, we did not forget you. There are 4 queues and the order that people arrive in is not the order they are served in.

Well, I could have avoided a good half hour of annoyance had someone told me that!! Never in the process (verbally or written) was I informed that once I was registered, that there were multiple queues. All I had to was the information I could see … everyone but me was getting service!  So I happened to be in the slowest queue but what blew me away was how my frustration was reduced once I knew that I was being treated fairly (very slowly but fairly).  I went back to reading my book and my name was called and I got my x-ray.

My experience at the radiology laboratory highlighted the power of information and communication with our customers.  This is exactly what we should provide our clients/customers in service organizations. While we may have implemented service management systems that show a person the status of their request, we almost never show them where they are in the queue (or queues!).  Imagine the impact on our clients if we could show them not only the status of their request AND where they were in relation to all the other requests in the queue or queues. This does pose a challenge for service delivery organizations because we would have to become more open and transparent about how we do our business.  Our ability (or inability) would be exposed for all to see!

 

I have been thinking a lot about re-engineering the service delivery model for the application services team that I lead. I have been guiding my team to think about:

“We deliver the platform and work with the business to provide services”.

Our applications team is made up of subgroups aligned by major application services.  Here are the major applications:

  • Business Intelligence
  • Collaboration Tools
  • Document Management
  • Email and Calendaring
  • ERP (Student, Finance, HR, Doc Mgmt)
  • Identity Management
  • Learning Management Applications
  • Microsoft Applications
  • Oracle Database
  • Portal (for students and employees)
  • SQL Server Database

Currently, there are 3 teams in place in our Business Application Services group. Here are the roles in each team:

Support Team

  • Oracle DBA
  • Document Management
  • Business Intelligence
  • Project Management
  • Business Analysis
  • Identity Management

Email and Collaboration Team

  • Email
  • Calendaring
  • Instant Messaging
  • Collaboration Platforms
  • SQL Server DBA
  • Microsoft Applications
  • Enterprise Portal

Developer Team

  • Oracle Developers
  • Lotus Domino Developers
  • Microsoft Developers
  • Java/Web Services Developers

I am interested in hearing from any of you that lead groups with similar responsibilities.  Do you have a suggested structure for me to consider?  Do you split your team based on roles (technology domains)  or by application (vendor) platforms? Do you split operational work from project delivery?  Does your governance structure influence your teams organization?

Any suggestions are very welcome and I hope to learn from some of your experiences.  Thanks in advance.

 

This is my review of this morning’s Architecture & Governance magazine webinar ”The State of EA: Is 2010 the Transformational Year?

Presenters:

  • George Paras, Editor-in-Chief, A&G, Managing Director, EAdirections – gparas@EAdirections.com
  • Alex Cullen, Vice President, Research Director, Enterprise Architecture, Forrester Research – acullen@forrester.com

1. What is the current state of EA? Forrester conducted a survey of 416 IT professionals and found the following:

  • Increasing awareness and acceptance of EA – this is change in that there is much more broad support for EA as a discipline in organizations
  • EA teams are part of senior IT management – more focus at a senior level instead of a tactical level in IT (* true in my case moving from a staff EA position to a management EA position)
  • Primary drivers for EA programs 1) better strategic planning 2) consolidation of technology 3) improve business agility4) enable business-IT alignment
  • Infrastructure, Security and Application architectures are the most complete, next Integration and Information architecture are underway and business architecture is the least complete
  • Where to architecture groups spend their time 1/2 time spent on non-project activities – supporting enterprise planning, strategic planning, collaborating with business and governance
  • CIOs look for EA to address their priorities – and guide and staff their EA teams accordingly – strongest technical thinkers, best problem solvers on EA team, business application area as EA lead

2. The Transformation of EA

  • IT expectations for architecture vary across 2 dimensions – Project to Strategy (Focus dimension) and Technology to Business (Orientation dimension)
  • Derived a 2 x 2 model – Project/Business = Business solution architecture, Strategy/Business = Business and IT strategy, planning and alignment, Project/Technology = Infrastructure and application platform selection, Technology/Strategy = Technology and infrastructure strategy and roadmapping
  • EA provides the most value when it is strategic and business focused but must overcome expectation barriers that EA is only about technology
  • Business focused EA should mean more business awareness, acceptance and support – more work to be done with lines of business and corporate management
  • Only 13% of corporate management actively supports EA vs 66% of CIO/Head of IT (* Is this a job for the CIO to educate their C-level peers?)
  • The correlation between business engagement and Business Architecture programs for improving support for EA in organizations – almost double the support from the business
  • The correlation holds for Information Architecture programs too – (* think of data and information as the currency that the business runs on)
  • Why the correlation for business and information architecture programs?
    • make EA engage with business leaders about their business
    • address problems at the boundary of business and IT
© 2007-2012 Enterprise Architecture in Higher Education - Leo de Sousa Creative Commons License
Enterprise Architecture in Higher Education by Leo de Sousa is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at leodesousa.ca.
Suffusion theme by Sayontan Sinha

Switch to our mobile site