 |
| Social Modeling for Requirements Engineering |
Now I am sure you are familiar with this scenario, especially if you work at a large organization, when you want to book rooms for meetings and the booking system says that its already booked by someone else? But then in reality its not being used? Well, to solve this issue, the current line of thought is a new meeting concierge application was to be to figure out who has been missing out on using their booked rooms for 2-3 times in a row and then 'reprimand' them with a message or some other manner. When the people designing the system told me about how they were trying to figure out how to ascertain if someone was indeed using the systems, something struck my mind.
How do the people who are stuck with the current systems work around the system? If we know the person who has blocked the room, we go over to the other person's desk and check with them and negotiate if we can get the room. Or we directly go and have a peep into the room to see if its indeed being used. Or we check with reception or who ever handles the room bookings. Then this idea came to me as a brainwave, out of nowhere since I had never thought about this problem before. What if we can allow the user to be able to communicate from within the system with the person who has pre-booked the room? What if there were an integration with OCS (or whatever IM is deployed) that allowed the user to chat with this other person? Or how about there is a 'button' there that lets the user to ask the other person if he would like to reassign the booking to him? They system could send an email to the other person and he could reply with a simple yes or no and the system would act accordingly?
Where the current approach is one of process & compliance, the later is one of enabling communication, especially with others in the organization whom you might not know because its a huge company? Well, we ourselves at Cognizant do have more than 100,000 employees worldwide and most of our buildings house thousands of employees. So it is not a remote possibility that the two users would not know each other.
So what was different in my approach to the problem? In real life the Actors of the system do not use the system to get this done. They interact with each other to negotiate. In traditional requirements gathering, we only try to figure out what the system should do, not what the actors do to get the job done. We cannot capture that as use cases or in UML. However, in an i* framework we really do try to figure out how the Actors interact with each other, what are their motivations, etc. Could i* framework have come up with what I got as a brainwave? I still do not understand i* properly, so hope to revisit the above scenario later and answer you.
Brilliant idea and also a common problem. Here is one method I use often to give the users visibility and accountability for this scenario some steps seem like dinosaur processes, but work through the entire example to discern benefits:
ReplyDelete(this assumes that the client has a system that includes the option to enter Items & some sort of workflow/task/appointment functionality)
A meeting room is just like a piece of inventory. I want all of the same reports & capabilities as I do with handling any other kind of item.
1. Create an Item called Meeting Rooms
2. Create each conference room under the main item as a serialized item. With most evolved/mature systems, this means that the Item/serial number will aslo be linked to a planning calendar. This adds in multiple additionals layers for reporting & analysis)
3. Next, create a workflow template that includes fields for start & end times and dates, plus fields to select the specific item & serial number (i.e. the room), plus other fields like subject & remarks/notes. I'd highly suggest adding in a 'closed' step in the process so we could see who booked by didn't use the room.
4. Educate the staff on the use of the workflow to book the rooms (select item, check serial [room] availability.)
At lowest level of the process: If I want to book a room, I'd first check the room's availibity. If it wasn't free during the time I wanted to book if for, I could reference the related workflow - check who has it booked and for what purpose, then communicate and negotiate with the person via remarks on the same worklow. With the right negotitation of coffee & donuts, I might get the origninal booker to reassign the room to my team for our much more important meeting. ;> One small click on the workflow button, and it is accomplished.
At a higher level, this enables us to run tons of reports: overall number of meetings booked, most frequently used rooms & by whom, peak hours, frequent purposes, rassigned rooms, bottlenecks, etc.
It works very effectively if done well. I use the same method where possible when creating Customer Support call ticket structures.Makes it very easy on the end user & builds in a whole layer of reporting capabilities.
Not sure this fulfills your idea of nirvana but would be happy to demo how this can work on various systems if you have any interest.