Friday, August 17, 2012
Sunday, August 28, 2011
Sidewalk: Democracy 2.0, participatory democracy - Part 1
Last 2 weeks, India witnessed an unprecedented nonviolent & peaceful agitation to pursue government and parliament to enact an anti corruption law. It involved one man, a Gandhian, named "Anna Hazare" going on fast demanding immediate enactment of the law. Thousands across India supported & participated in the agitation. As the health of the fasting 74 year old Anna deteriorated government, parliament and representatives of the so called "civil society" worked together to resolve the impasse. While, the law has not yet been enacted, On Aug 27, 2011, 2 houses of the parliament passed a resolution unanimously to enact a strong anti corruption law. This has been now considered a historic day by many. While others, although in minority feel that the agitation and means adopted to pursue the government and parliamentarians were undemocratic. Those who have opposed and criticised the movement have not provided answers as to how people at large can be involved in democratic process going beyond voting in elections once in 5 years.
To my mind, the biggest ill with the largest democracy in the world is that it is not as participatory as it should be. Having said so, I have lot of questions. What is participatory democracy? Does participatory democracy mean voting once in 5 years alone? What are the elements or aspects of democracy in which people can participate? What are legitimate, constructive, and decentralized ways by which people at large can be involved in policy making making process? Will such a process be feasible,effective and efficient? Can Information Technology play a role to make participatory democracy a reality?
I never thought that political science could be so interesting. I am not a student of political science. But I must say that it is the right time to be a student of political science. If we feel that recent agitation involving scores of citizens across India was not democratic, then we must find & come up with ways & means by which citizens can be enabled to participate in democratic processes in democratic ways.
Interestingly, when I googled on participatory democracy, Google threw up a Wikipedia page on participatory democracy: http://en.wikipedia.org/wiki/Participatory_democracy
I also came across at least 3 initiatives where citizens are or are being involved in framing the consitution:
* Iceland crowdsources its next constitution
* Egypt's Watiqah (Basic Document) for human rights principles to be enshrined in constitution
* Morocco's crowdsourcing initiative for consitituional ammendments
While Democracy 2.0 is much beyond crowdsourcing, I feel it is time for Democracy 2.0.
To my mind, the biggest ill with the largest democracy in the world is that it is not as participatory as it should be. Having said so, I have lot of questions. What is participatory democracy? Does participatory democracy mean voting once in 5 years alone? What are the elements or aspects of democracy in which people can participate? What are legitimate, constructive, and decentralized ways by which people at large can be involved in policy making making process? Will such a process be feasible,effective and efficient? Can Information Technology play a role to make participatory democracy a reality?
I never thought that political science could be so interesting. I am not a student of political science. But I must say that it is the right time to be a student of political science. If we feel that recent agitation involving scores of citizens across India was not democratic, then we must find & come up with ways & means by which citizens can be enabled to participate in democratic processes in democratic ways.
Interestingly, when I googled on participatory democracy, Google threw up a Wikipedia page on participatory democracy: http://en.wikipedia.org/wiki/Participatory_democracy
I also came across at least 3 initiatives where citizens are or are being involved in framing the consitution:
* Iceland crowdsources its next constitution
* Egypt's Watiqah (Basic Document) for human rights principles to be enshrined in constitution
* Morocco's crowdsourcing initiative for consitituional ammendments
While Democracy 2.0 is much beyond crowdsourcing, I feel it is time for Democracy 2.0.
Labels:
Democracy 2.0,
Sidewalk
Sunday, November 28, 2010
Sidewalk: Business Design Principles
Sometime back, I was invited to participate in a Round-Table discussion by Welingkar Institute @ Matunga, Mumbai. The theme of the roundtable was Empowering India. At the end of the round-table, participant's views were sought on new breed of MBAs - Business Designers & Business Design.
Business Design was very aptly defined by one of the participants as design of Strategy, Product, and Process. Organisations have specific functions which take care of Strategy, Product and sometimes even process design. Process design though is largely addressed through quality initiatives like ISO, Six Sigma and TQM. Now when an MBA is packaged as a Business Designer, the package indeed looks attractive. Very raraly though MBA would get an opportunity to work on all the 3 aspects of Business Design simultaneously with the exception of Consulting.
I have had an opportunity to go through Business Design, when we launched IndiaFirst Life Insurance, the latest entrant in life insurance sector india. My work largely focussed on operations and process design, and here are my inputs:
1. Focus on the customer and end user
May sound a bit cliched, but remember that the product and process & systems you are designing are for customers and users respectively. Understand the pain areas & challenges of your customer / user, while carrying out your business design. A solution or design that addresses end user's challenges automatically improves the acceptability of the solution.
2. Business Design has to be contextual
While designing process or product, you needs to see the context in which they are applied. When IndiaFirst project team was formed, most of us came to the table with strong agency driven life insurance company background. Whereas IndiaFirst is largely a bancassurance company. When we were made to see our business in the context of bancassurance, we realised that agency driven life insurance operational processes could be improved upon significantly to establish low cost n faster TAT operations. What works in one environment may not work in another. What works for an old organisation may not work for new organisation, and vice-versa. So, understands the context before designing business.
3. Design the blueprint & establish a roadmap
In case of operation or system design, make sure that the blue-print of the design is ready in sync with long term business goals. Business designers tend to typically trade short objectives for long term goals due to cost and time constraints. Any operations or systems built keeping in mind short term goals involve rework and waste. Make sure that you understand long term business objectives, draw a blue-print identifying all the components of the solution and define implementation roadmap in case you have to opt for an incremental approach to implementation.
4. KISS - Keep it Simple n Stupid, stick to basics
Innovation is a buzz word today. If you do not innovate you are out of the game. Designers, as a result, are always under tremendous stress to innovate n come up with completely radical n new ideas. As a result, most of the time, business designers over-engineer & over-complicate processes and products. Avoid over-use or emphasis on technology.
Business Design was very aptly defined by one of the participants as design of Strategy, Product, and Process. Organisations have specific functions which take care of Strategy, Product and sometimes even process design. Process design though is largely addressed through quality initiatives like ISO, Six Sigma and TQM. Now when an MBA is packaged as a Business Designer, the package indeed looks attractive. Very raraly though MBA would get an opportunity to work on all the 3 aspects of Business Design simultaneously with the exception of Consulting.
I have had an opportunity to go through Business Design, when we launched IndiaFirst Life Insurance, the latest entrant in life insurance sector india. My work largely focussed on operations and process design, and here are my inputs:
1. Focus on the customer and end user
May sound a bit cliched, but remember that the product and process & systems you are designing are for customers and users respectively. Understand the pain areas & challenges of your customer / user, while carrying out your business design. A solution or design that addresses end user's challenges automatically improves the acceptability of the solution.
2. Business Design has to be contextual
While designing process or product, you needs to see the context in which they are applied. When IndiaFirst project team was formed, most of us came to the table with strong agency driven life insurance company background. Whereas IndiaFirst is largely a bancassurance company. When we were made to see our business in the context of bancassurance, we realised that agency driven life insurance operational processes could be improved upon significantly to establish low cost n faster TAT operations. What works in one environment may not work in another. What works for an old organisation may not work for new organisation, and vice-versa. So, understands the context before designing business.
3. Design the blueprint & establish a roadmap
In case of operation or system design, make sure that the blue-print of the design is ready in sync with long term business goals. Business designers tend to typically trade short objectives for long term goals due to cost and time constraints. Any operations or systems built keeping in mind short term goals involve rework and waste. Make sure that you understand long term business objectives, draw a blue-print identifying all the components of the solution and define implementation roadmap in case you have to opt for an incremental approach to implementation.
4. KISS - Keep it Simple n Stupid, stick to basics
Innovation is a buzz word today. If you do not innovate you are out of the game. Designers, as a result, are always under tremendous stress to innovate n come up with completely radical n new ideas. As a result, most of the time, business designers over-engineer & over-complicate processes and products. Avoid over-use or emphasis on technology.
Labels:
Business Design
Saturday, August 07, 2010
Sidewalk: IT Process Model
In one of the on-line forums, a colleague posted question on processes in end user organisations to ensure effective delivery by IT functions.
A number of times, while implementing any process framework, the focus is on the letter rather than the spirit of the framework. Process framework needs to be adapted and not adopted. The emphasis is always implementing processes as they are rather than customising them to the needs of the organisation. There are well established process frameworks like COBIT and ITIL. I would propose the following IT Value Chain process lifecycle framework, which would have core value chain processes and support processes. Typically, core value chain processes would be:
> Strategise and Architect: Formulate IT Strategy and design IT systems and infrastructure Architecture
> Plan & Evaluate: Plan system and infrastructure implementations and evaluate & select system and infrastructure technologies
> Develop and Implement: Develop and Implement IT system and infrastructure projects
> Enhance & Maintain: Enhance & maintain IT systems and infrastrcture
The above processes could be drilled down into sub-processes and activities such as RFP, System Delivery Management, Change Management, etc.
Examples of support processes would be: IT Governance, Information Security Management, Asset Management, IT Procurement Management, IT Payments Management, etc.
What do you think?
A number of times, while implementing any process framework, the focus is on the letter rather than the spirit of the framework. Process framework needs to be adapted and not adopted. The emphasis is always implementing processes as they are rather than customising them to the needs of the organisation. There are well established process frameworks like COBIT and ITIL. I would propose the following IT Value Chain process lifecycle framework, which would have core value chain processes and support processes. Typically, core value chain processes would be:
> Strategise and Architect: Formulate IT Strategy and design IT systems and infrastructure Architecture
> Plan & Evaluate: Plan system and infrastructure implementations and evaluate & select system and infrastructure technologies
> Develop and Implement: Develop and Implement IT system and infrastructure projects
> Enhance & Maintain: Enhance & maintain IT systems and infrastrcture
The above processes could be drilled down into sub-processes and activities such as RFP, System Delivery Management, Change Management, etc.
Examples of support processes would be: IT Governance, Information Security Management, Asset Management, IT Procurement Management, IT Payments Management, etc.
What do you think?
Labels:
IT Management,
IT Process Lifecycle
Sunday, December 27, 2009
Information Security: What comes first - Business Impact Analysis or Risk Assessment?
Last week, I attended a 2 day course on ISO 27001: Information Security Management System. The course was meant for auditors and as part of the course we discussed the relevance of Business Impact Analysis (BIA) and Risk Assessment (RA) in the context of Information Security Management System (ISMS). The questions that was asked was what comes first: BIA or RA?
My immediate response was Risk Assessment. As an organisation, one would need to identify all risks, Rank the risks based on the quantum of impact and probability of occurance, and finally Formulate mitigation plan for top risks. By my argument, business impact analysis was a sub set of Risk Assessment.
However, there was a counter argument to this. For large organisations, it is time and effort intensive exercise, if not impossible, to identify all risks and assess their impact. So rather than carrying out risk assessment, it would be a lot easier to carry-out Business Impact Analysis upfront. This would involve identifying critical activities of the business value chain or critical assets and assessing the impact (in terms of loss of production, loss of revenues, loss of person hours of time, etc) to the overall business in case of their non performance. Risk assessment would then be carried out to identify the risks that would impact these critical value chain activities or assets adversely, which is followed by formulating a mitigation plan for the top risks identified.
On the second thoughts the later approach seemed very rational and logical. What do you think?
My immediate response was Risk Assessment. As an organisation, one would need to identify all risks, Rank the risks based on the quantum of impact and probability of occurance, and finally Formulate mitigation plan for top risks. By my argument, business impact analysis was a sub set of Risk Assessment.
However, there was a counter argument to this. For large organisations, it is time and effort intensive exercise, if not impossible, to identify all risks and assess their impact. So rather than carrying out risk assessment, it would be a lot easier to carry-out Business Impact Analysis upfront. This would involve identifying critical activities of the business value chain or critical assets and assessing the impact (in terms of loss of production, loss of revenues, loss of person hours of time, etc) to the overall business in case of their non performance. Risk assessment would then be carried out to identify the risks that would impact these critical value chain activities or assets adversely, which is followed by formulating a mitigation plan for the top risks identified.
On the second thoughts the later approach seemed very rational and logical. What do you think?
Labels:
Information Security
Sunday, December 20, 2009
Sidewalk: Do BAs need to have domain knowledge?
I always thought that the answer to this question was very obvious! A big YES! But a recent discussion on IIBA group on LinkedIn generated mixed responses. In fact a large number of respondents felt that business analysis method and tools were more important than the domain knowledge.
In my opinion, Business Domain knowledge alone may not guarantee success to a business analyst but lack of it would certainly make his / her job difficult. And the same argument holds good for Business Analysis method. And this is because Business Analysis is as much an individual skill as it is a science.
While there seems to be no debate on the need to know Business Analysis method, I thought I should elaborate my points in favour of domain knowledge. For that I would like to start with the definition of Business Analyst (BA) role is.
Primary role of the BA is to provide business solutions (with or without involving technology) to business issues, by assessing buisness problems, and identifying root causes. The success of the BA role lies in the benefit that the solution provides to the business either in terms of savings in costs, improvement in productivity, increase in revenues and so on. BA should also be able to provide measurement framework so that effectiveness of solutions can be monitored and further improved upon.
Most of the time BA role is misunderstood as Project Managers, System Analysts (IT System designers, etc., in which cases domain knowledge may not be as important as the method.
Now some of the reasons why Domain knowledge is important:
#1 - Domain knowledge makes easier for BA to connect with Business Users
In order to understand business problems, BA is expected to interact with business users to map business processes, gather business data, discuss their analysis and findings, etc. A number of bsuiness users get extemely frustrated if business analysts ask basic questions about the business as to what (rahter than how and why) the business happens. For example, in an assignment to improve New Business Process cycle time in life insurance, Business Analyst cannot be expected to ask questions such as What is term insurance, What is ULIP, What is underwriting, Whether a pension plan requires underwriting. Such basic questions would lead to loss of credibility of the BA with the users and hence the solution that is being proposed.
#2 - Lack of Domain knowledge may lead to delays in providing the solution
BA may spend most of his / her time understanding the basics of business rather than spending time in carrying out the actual business analysis work of mapping business processes, collecting & analysing business data, and so on.
#3 - Domain knowledge makes understanding and analysing business issues a lot easier
Domain knowledge may help BAs to quickly identify the real business issues and real root causes rather than getting bogged down by peripheral issues and root cuases. This may help the BA to offer better and quality solutions to business users.
In summary, domain knowledge is not a replacement to Business Analysis method. Method may be a necessary condition but certainly not a sufficient condition to be a good Business Analyst.
In my opinion, Business Domain knowledge alone may not guarantee success to a business analyst but lack of it would certainly make his / her job difficult. And the same argument holds good for Business Analysis method. And this is because Business Analysis is as much an individual skill as it is a science.
While there seems to be no debate on the need to know Business Analysis method, I thought I should elaborate my points in favour of domain knowledge. For that I would like to start with the definition of Business Analyst (BA) role is.
Primary role of the BA is to provide business solutions (with or without involving technology) to business issues, by assessing buisness problems, and identifying root causes. The success of the BA role lies in the benefit that the solution provides to the business either in terms of savings in costs, improvement in productivity, increase in revenues and so on. BA should also be able to provide measurement framework so that effectiveness of solutions can be monitored and further improved upon.
Most of the time BA role is misunderstood as Project Managers, System Analysts (IT System designers, etc., in which cases domain knowledge may not be as important as the method.
Now some of the reasons why Domain knowledge is important:
#1 - Domain knowledge makes easier for BA to connect with Business Users
In order to understand business problems, BA is expected to interact with business users to map business processes, gather business data, discuss their analysis and findings, etc. A number of bsuiness users get extemely frustrated if business analysts ask basic questions about the business as to what (rahter than how and why) the business happens. For example, in an assignment to improve New Business Process cycle time in life insurance, Business Analyst cannot be expected to ask questions such as What is term insurance, What is ULIP, What is underwriting, Whether a pension plan requires underwriting. Such basic questions would lead to loss of credibility of the BA with the users and hence the solution that is being proposed.
#2 - Lack of Domain knowledge may lead to delays in providing the solution
BA may spend most of his / her time understanding the basics of business rather than spending time in carrying out the actual business analysis work of mapping business processes, collecting & analysing business data, and so on.
#3 - Domain knowledge makes understanding and analysing business issues a lot easier
Domain knowledge may help BAs to quickly identify the real business issues and real root causes rather than getting bogged down by peripheral issues and root cuases. This may help the BA to offer better and quality solutions to business users.
In summary, domain knowledge is not a replacement to Business Analysis method. Method may be a necessary condition but certainly not a sufficient condition to be a good Business Analyst.
Labels:
Business Analysis,
Sidewalk
Saturday, September 12, 2009
Digital Convergence - A round-table at Welingkars', Mumbai
I was invited to participate in a round-table discussion organised by Welingkar institute. The topic was Digital Convergence.
Before I share my takeaways and thoughts on the topic, I must say that it was a very professionally organized event. Students management was excellent and so was the format of the round-table, conduct of the participants & moderation. Welingkars' have amazing infrastructure for a business school. So, while the round-table discussion took place in their campus in Mumbai, it was also attended over video conference by their students and faculty of campus in Bangalore, an illustration of digital convergence!
What is digital convergence?
In my humble opinion, digital convergence is the convergence of:
- the content.... audio, video, data
- the media of delivery of the content.... various types of wired and wireless network & protocols, and
- the devices receiving, storing (?) and processing the content... desktop, laptop, mobile, tv, PDAs, kiosks
By convergence I mean interoperability and compatibility of the content, media and devices with each other. This means any content should be feasible to be delivered over any media on to any device that the user is using to receive and use the content.
Now, if this is the broad definition, then I guess, we haven't seen anything yet. This is because on one hand standards and protocols need to evolve, the media and end user devices must support the standards and protocols that are evolving. And on the other hand, regulations and laws need to take shape too.
What is drving Digital Convergence:
A number of reasons:
Convenience & End user experience - Consumers have to deal with multiple types contents on multiple types of devices. They are demanding convenience.
Affordability & Costs - Technology is making it feasible for businesses to deliver to their consumers highly cost effective solutions.
Reach and Penetration - It gives businesses tremendous opportunity to reach untapped or unreachable markets and consumers!
The missing link:
The student presentation at the beginning of the session and subsequent discussions mostly centered around applications developed for business to consumers space. My point to the forum was: Is digital convergence only about Business to Consumer space. Isn't Digital Convergence relevant for inter-enterprise or intra-enterprise applications? What do you think? Do you have any success stories to share?
Before I share my takeaways and thoughts on the topic, I must say that it was a very professionally organized event. Students management was excellent and so was the format of the round-table, conduct of the participants & moderation. Welingkars' have amazing infrastructure for a business school. So, while the round-table discussion took place in their campus in Mumbai, it was also attended over video conference by their students and faculty of campus in Bangalore, an illustration of digital convergence!
What is digital convergence?
In my humble opinion, digital convergence is the convergence of:
- the content.... audio, video, data
- the media of delivery of the content.... various types of wired and wireless network & protocols, and
- the devices receiving, storing (?) and processing the content... desktop, laptop, mobile, tv, PDAs, kiosks
By convergence I mean interoperability and compatibility of the content, media and devices with each other. This means any content should be feasible to be delivered over any media on to any device that the user is using to receive and use the content.
Now, if this is the broad definition, then I guess, we haven't seen anything yet. This is because on one hand standards and protocols need to evolve, the media and end user devices must support the standards and protocols that are evolving. And on the other hand, regulations and laws need to take shape too.
What is drving Digital Convergence:
A number of reasons:
Convenience & End user experience - Consumers have to deal with multiple types contents on multiple types of devices. They are demanding convenience.
Affordability & Costs - Technology is making it feasible for businesses to deliver to their consumers highly cost effective solutions.
Reach and Penetration - It gives businesses tremendous opportunity to reach untapped or unreachable markets and consumers!
The missing link:
The student presentation at the beginning of the session and subsequent discussions mostly centered around applications developed for business to consumers space. My point to the forum was: Is digital convergence only about Business to Consumer space. Isn't Digital Convergence relevant for inter-enterprise or intra-enterprise applications? What do you think? Do you have any success stories to share?
Labels:
Digital Convergence
Subscribe to:
Posts (Atom)