SAP is deeply involved in the AWS Cloud and has been supporting the company’s internal systems since 2008 (see a video here and a wiki here). As a SAP Partner, Capgemini leveraged its strong relationship with the company to deploy a Proof of Concept (POC) landscape in the AWS Cloud in October 2009.

I’m pleased to say, it’s 2010 and the challenge has been met. Our SAP Solution Centre boasts a solid understanding of SAP in an Amazon Cloud environment. How? Simple. We put SAP in the Cloud to prove to ourselves it could be done, then built it for our clients to spread the word.

So what exactly did we build?

Currently the SAP Solution Centre has a Proof of Concept (POC) laboratory running in the AWS Cloud, primarily on Windows, but also on Linux-based servers, a key part of our next phase of development.

As the person responsible for the technical aspects of the landscape, I was part of the team that deployed, at various stages, the following systems from the SAP Business Suite 7 portfolio:

• Enterprise Core Component 6 (ECC 6) – on Windows 2003 & DB2 9.7
• Business Warehouse (BW 7.0) – on Windows 2003 & DB2 9.7
• Portal 7.0 on Windows 2008 & SQL Server 2008
• Customer Relationship Management (CRM 7.0) on Windows 2008 & DB2 9.7
• Solution Manager on Windows 2008 & SQL Server 2008

After signing a contract with a major British Utilities services company just before Christmas, the newly appointed Capgemini project team quickly found that there was no way to provision the required hardware for a blueprint system through normal channels. The project had to start within days of the contracts being signed, and the team was ready to move across multiple geographies.

In order to keep the contract on-time and on-budget, and ensure the climate was right to commence, it was decided to build or ’stand up’ the environment in the AWS Cloud. In four days we were able to build the above landscape in the AWS Cloud and have it ready for functional consultants to begin and complete work in 48 hours. In a traditional hosting environment this landscape would have taken weeks to create, simply because of the number of people it involves.

However, rapid deployment is not the only driver for the AWS Cloud as cost is also a key benefit. The solution outlined above has been deployed for approximately 40% of the cost of a standard hosting landscape. So successful was the deployment, it turned heads within our SAP Solution Centre. Within days, several consultants were exploring what part of their SAP landscapes could be put into an AWS Cloud.

This is a new and fresh challenge, as we seek to ensure that this solution is only used at the right time and in the right way. To that end, below is a framework that the Capgemini team has constructed to assess whether or not a solution can be deployed safely in the AWS Cloud.

Some of the high level criteria are:

·         Time constraints - How quickly do the systems really need to be available?  

o    Everyone wants their systems immediately, but when does the system actually need to be available?

·         Cost requirements - What are the cost drivers for the customer?  

o   Of course everyone wants to use the least costly option, but some drivers for reducing costs are more compelling than others, and they should not be taken at the expense of the project outcomes

·         Who is responsible for provision of the systems? - Is it Capgemini or the client?

o    This has a huge bearing on whether a landscape can and should be deployed into the AWS Cloud.

·         SLAs - Is there an SLA for service provision?  

o   The AWS Cloud has no SLAs in place for a normal account, it is built upon the concept of disposable servers and computing power

·         Access requirements - Who needs access and from where?

·         Data security - What sort of data will be held within the system?  

o   Although AWS has passed several security certifications, there is still some fine tuning required to the security model in relation to SAP

During the last 5 months, we have been able to move from a theoretical exercise of deploying SAP in the cloud to actually having a live SAP project deployed for a major British company as part of an overall programme that runs into the £100’s of millions. The learning curve has been substantial, especially moving from a POC environment to a live environment, as there are many things that are often forgotten in a POC. We have encountered several challenges during our landscape deployments, but we have resolved them and provided more functional and flexible environments in doing so. Technology always moves quickly, and all too often companies are guilty of claiming they can do something or that something is possible before it’s actually been done. We’re proud to say that we’ve not fallen into that trap.

In terms of next steps, Capgemini is working exclusively with SAP to provide better applications to help manage systems in the AWS Cloud and to expand our expertise into other areas, like SAP on a Windows Azure platform or IBM’s Compute Cloud. Following our success with Amazon, both companies are very interested in working with Capgemini to deploy SAP landscapes on their Cloud platforms.

The possibilities that the Cloud presents are immense, and on a personal level, I honestly can’t remember being so excited about being involved with something at such an early stage. However, in order to realise those immense possibilities, we as trusted advisors must guide our customers to use the right tools and methodologies at the right times. We must not allow ourselves to be prejudiced against traditional methods if they are right for the circumstances. This can spoil the party for everyone.

This entry was written by Chris Kernaghan. Chris works in the SAP Solution Centre within Technology Services in Capgemini UK, he specialises in SAP upgrades and infrastructure migrations.

• Organize BRM projects in a capacity building way (looking over the shoulder, collaborating, do it yourself) in this way when we`re gone the business can and will survive;


• Start BRM projects small but practical (Prototype/POC from the get go), with a real to solve business issue;


• Design parallel and mostly supportive of the 'real life'BRM projects , business changes faster than you can design! and


• Introduce with the start of BRM project a new role in the business organization, one of the business engineer, and give him ownership of applicable business logic.

• Subscriptions are the New BLACK. (+ why Facebook, Google, & Apple will own your wallet by 2015) - The key to success in payment systems is to begin with the foundation of frequent-use products, so that users won't forget their passwords. Whether intentional or not, Facebook has played this game to perfection.
• Pure CSS Coke Can (3D) By a combination of the CSS1 properties background-attachment and background-position, 2D displacement maps could be created and, by scrolling, the displacement map would be applied to different parts of the texture (a background image).
• Now you can play Tetris on your TV Game company Oberon Media has somehow found something in common with both the Tetris Company and the Dish Network.
• Gartner Reveals Five Social Software Predictions for 2010 and Beyond “Success in social software and collaboration will be characterized by a concerted and collaborative effort between IT and the business”
• Enterprise 2.0 Adoption – Strategic and Tactical Considerations No conversation about Enterprise 2.0 proceeds very far without coming to the idea of Return on Investment (ROI).

Light reading:

• iPad vs Flash: Developers Choose Wisely
• Why You Should Be Afraid Of Internet Censorship in Australia, Even If You Don’t Live There
• Now more than ever, employers and HR pros are digging into your web presence.
• Innovation Teams Lack Data, Structure
• Forget Google, social search is all about mobile

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

A friend of mine helped his mom switching to Firefox (about six years ago). He made it simple for her by putting two icons on her desktop one named 'Proper Internet'  (launching the Firefox web browser) and the other one was named 'Internet' (launching Internet Explorer for sites that couldn't be rendered properly in Firefox). He didn't do this because his mother wanted to change, but because he loved Firefox so much. His mother did not care, she had Proper Internet and Internet en she even did not notice the difference.

It is almost like buying a new car. Most people buy a new car because they have to and some because they want to. Some of the buyers care a lot about brand others care more about color or certain functionality and others don't care at all, as long as it helps them to go from location A to location B and it is not too expensive. Most people care in the same way about browsers and most people don't care at all. So if you don't tell the no-carers that there is a different browser that could enhance their experience (Chrome is all about speed), they won't switch, since what they have is good enough (every browser they have is free, renders 98% of the websites correct, renders 100% of the websites good enough and helps them in visiting the things they want).

If you want to build market share you either build a very good product and trust word of mouth marketing, however if you have plenty of cash (as Google has) you can do a bit extra and involve more traditional media such as billboards and traditional advertisting in papers. And in a world where hardly anybody knows what a browser is, word of mouth is not so effective.

I wonder how Google will solve this issue with Chrome OS, since operating systems are becoming the same kind of commodity as browsers already are. They'll figure out, don't you think?

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

Smart use cases are a great technique for specifying standardized requirements in many types of projects. Over the past few years we have smart use cases being modeled and written in projects using Java and .NET, as you might expect, but also in Sharepoint projects, business intelligence, service oriented projects and even SAP implementations.

Stereotypes drive standardization
Standardization of your requirements can be an important driver to simplify software development and software rejuvination projects. An important addition to the smart use case modeling technique is the use of smart use case stereotypes.

These stereotypes represent often occurring patterns of requirements. Well known our the stereotypes manage, that represents a maintenance use case on some domain object, or search, which helps users to find a particular domain object, guided by search criteria. Other known stereotypes include select, master-detail, view, and report. As you might expect, these stereotypes all deal with user interaction.

Over the years however, we have gathered quite a few stereotypes, also in other fields. We have described for instance stereotypes that deal with Extraction Transformation Load (ETL) processes in data warehousing projects, such as aggregate, calculate and load.

Stereotypes not only help to put focus in modeling workshops, they also facilitate more easy project estimates, and even allow for straightforward code generation and isolated testing. Even better, once you marked the stereotypes (and put them into a UML profile), it will allow you to create much richer use case diagrams, modeling in colour.

Modeling in colour using (profiled) smart use case stereotypes

Slicing service oriented projects
More recently we have applied smart use cases to service oriented projects. These projects tend to be more complex than regular software development projects, and focus around more elaborate architectures Service oriented projects mostly include:

• Flexible front-end features. These can be either web pages, mobile phone front ends, Windows native applications or even Flash or Silverlight applications.
• Process-oriented middleware. Service oriented processes always implement business processes. These business processes or workflows are run in middleware, more specifically in an enterprise service bus (ESB), although having such a bus is not mandatory. There are many vendors supplying busses, such as IBM, SAP, Oracle and Microsoft.
• Stable services. A very important part of service oriented projects consists of the discovery and realization of services. Most often these services are implemented on top of existing legacy or packaged systems.

These slices in service oriented project all serve particular means and responsibilities. The approach to modeling smart use cases in such projects offers quite a few benefits. Next to modeling the front-end use cases, smart use cases help to model the business processes, and discover the required services.

Stereotypes for service oriented projects
In recent projects, that involved such complex service oriented architectures, we have gained a lot of experience in identifying and modeling smart use cases. This week we have analized a number of such models from different projects. This results in a set of new smart use case stereotypes, specifically targeted at the processes that run in middleware, and the encapsulation and execution of services.

One of the smart use case diagrams we’ve investigated

Next to our well-known front end smart use case stereotypes, the new service oriented stereotypes include the following: process, aggregate, dispatch, validate, read, write and inform. I will elaborate on these stereotypes in the next sections.

Stereotype process
A use case of stereotype process executes a business process. In most cases it delegates the execution of services to other use cases, often of types aggregate and dispatch.

The process use case is in the lead, and uses the post-conditions from called use cases to steer the process. This type of smart use cases is generally implemented in the enterprise service bus, such as BizTalk or SAP Xi.

Stereotype aggregate
An aggregate typed smart use cases generally is used to create a single response to a request.

The stereotype is called aggregate as these use cases trigger other smart use cases, othen of types dispatch and read, and aggregates the results from these use cases into a singel response.
Stereotype dispatch

Smart use cases of type dispatch are intended to link the aggregate or process types use cases to services that either require some mapping, or typically run outside the organization.

Mapping is often required, as the available services do not always deliver what is required by the calling use cases. The dipatch smart use cases performs the mapping (hence and forth) and relays the work to the actual service, that is often of type read or write.

Stereotype validate
Executing business processes often include specific validation services, for instance to see if an customer is allowed to add a particular product to their subscription (as in one of the projects we investigated). Smart use cases labeled with the validate stereotypes return a single answer, that can be either a yes or no response, or a single value from a limited list of possible codes.

In cases of more complex validation, for instance when match-making between different back-end or external systems is required, the validate use case relays fetching the required information to dispatch, read or even aggregate smart use cases.

Stereotype read
Smart use cases with the read stereotype are the most basic services. Here one or more domain objects or entities are returned from a back-end system. This often includes compressing a whole hierarchy (such as with many SAP systems), such as a product hierarchy into a single returning message.

Stereotype write
In reverse, write typed smart use cases will pick up such a compressed hierarchy that is input to the use case, distribute the hierarchy into the back-end systems and persist it.

Stereotype inform
During the execution of a business process, the actual user of the whole process (being the actor of the user goal level use case initiating the process) needs to be informed of the status. The actor might get an email, such as in a subscription process to acknowledge successful subscribing, or be sent a letter. Other alternatives are of course also possible.

The inform use case is responsible for merging the text of the message being sent with the actual domain objects the use case model evolves around.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com
www.smartusecase.com

With the advent of a host of social media sites and the topic shooting to popularity, most people and organizations seem to feel that by having, just a presence on social media sites, one can sit back and reap its benefits. When in reality just by creating a twitter profile or searching for candidate profiles on LinkedIn may not bring them the returns on social technologies. It surely is the first step in the right direction, but assuming that one could see startling results with just that, will be foolish. As we say 'What goes around comes around' - expect very little returns (or responses) from the social technologies if you are not willing to share or participate. It’s time we realize social media is about being social – contribution, conversation, interaction, engagement (and the likes) with your employees, customers, or partners is what will bring benefits and remember the social technologies are only the enablers!

Another point the above article also brings out (and I am glad) is that, it’s not about using the most "hyped" social media site and more so - one size definitely doesn't fit all. Each tool has a specific objective of existence and though they seem user-friendly & popular, understanding their application in real-life business scenarios is equally difficult & important. There is a lot that goes into, before one starts implementing and using these tools. It really isn't another dot-com-bubble-kinds (that will go bust) that we are seeing so many strategy/consulting firms trying to help organizations in understanding how they can leverage from social media. Basics like knowing your pain-points, finding the best fit solution and customizing it to solve your real-life problem is the real deal. We really need to have a methodology / framework that will help in solving the business issues using social technologies, be it internal employee collaboration, interacting with customers or maintaining relationship with business partners. We all know this is still a fairly new playground for most of us (consulting firms & their prospective clients) and that makes it all the more important to have the fundamentals set right because each of us have a role to play. This just re-emphasizes the huge potential and opportunity for social business consulting & strategy practice and particularly the need for a formal approach and framework guiding social business engagements has, in today's world.

So, in conclusion - we just have to get social, in the real sense!

Nikhil Nulkar is a knowledge management consultant within Capgemini and is passionate about web2.0, specifically in enterprise2.0 & social media. Want to know what he is up to? Follow him on Twitter

Laurence Buchanan leads CRM within Capgemini's Technology Services business in the UK. Follow him on Twitter or connect on Linkedin. This post was first published on www.thecustomerevolution.com

What is Gravity?
Google Wave has been around for a few months now and though the hype is fading away we are seeing more and more practical use-cases in the enterprise. One excellent example is SAP's Business Process Modelling tool gone collaborative; Gravity. We have been fortunate to work with a prototype version of Gravity with access to the minds behind the concept. Gravity is a Business Process Modeling tool which can be accessed as a gadget in the Google Wave client. This integration in Google Wave allows for collaboration over time and / or near real time, on business processes. This model is exportable to Netweaver BPM via BPMN 2.0 XML, thus making it a fully integrable modelling tool for use in an SAP landscape. Still puzzled? check this video with an explanatory example:

Gravity is a proofing point for Google Wave usefullness for enterprise scenario's; it boosts Google Wave’s "corporate credibility".

What are we using Gravity for?
We are using Gravity to model user interaction and flow in an iPhone application within a demonstration scenario for SAP and REST.

To demonstrate the value of REST in combination with SAP, we are developing an iPhone app that helps consumers search for recipies and subsequently translate the recipie into actual products available in the supermarket of their choice. In particular, this translation takes food allergies into consideration. We use REST to obtain ingredients, product data and allergy information from SAP.

The advantage to consumers is an almost instant overview of what products should be bought to cook a recipy based on food allergy and the actual products available in the supermarket. Based on a cross reference of personal profiles containing info. on Hypo allergenics (?) and PIM data from SAP.

Gravity helps us quickly model the steps taken by system and end-users to use our application. In particular, the collaboration features help out our cross-displinary team work from different locations and with different time schedules.

Our experience
Prototype alert: many features are still unimplemented such as selecting multiple objects, changing connections, annotating selects, etc. However, we are very enthousiastic in our first conclusions from working with Gravity:

• Gravity is very intuitive and easy to use, the wysiwig and drag and drop interface combined with a no frills approach allows users to hit the ground running;
• Integration in Google Wave helps to not only document the results but also the decision and brianstorm processes because history and context is retained within the Wave;
• Collaborative editing works quite well both over time and distance and updates can be traced live allowing for immediate feedback and thus real-time collaboration;

Opportunities for value and growth
From our point of view, at this time Gravity seems most suited for high level process discussions with the client or within teams in earlier stages of process driven projects. Gravity fits in the SAP strategy for BPX and gives process owners, consultants and experts a tool to collaborate around, brainstorm on, explain and present process related activities.

Gravity seems extremely well suited for Geographically spread organisations. Collaboration across time-zones as is often the case with the global increase of outsourced and licesned work or projects.

The benefit of a Google Wave is that it is not limitied by access to corporate systems and firewalls for collaboration. However, If need be an export to Netweaver BPM is possible from where BPM experts can pick up and implement in the wider SAP landscape.

Gravity in a Wave allows for excellent documentation of the decisioning and ideation process and the discussions around it. The non-technical and functional documentation of a project that at times is vitally important but unfortunately often lost.

Conclusion:
It's not done yet, many basic features and nice extras still need to be implemented. However, Gravity provides us with a glimpse of what collaborative discussion and modelling could be like in a hybrid Service oriented landscape mixing Cloud based and proprietary architectures. We are very confident that SAP will be able to implement typical editing options such as multiple select, better support for drag and drop etc. And hope for more support of typical modeling methodologies such as UML.

On that note, if other model types would be implemented. Which UML models would you like to work with in Gravity?

Niels van der Zeyst is a Business Technologist at Capgemini. You can follow Niels on Twitter http://twitter.com/zeyst or contact him directly via niels.vander.zeyst@capgemini.com.

Maarten Engels is Managing Consultant at Capgemini where he is the leader of the SAP Infrastructure and Architecture profession group.

• Defining Enterprise 2.0
  Is the technology freeform, frictionless and emergent?
• Social circle and content – Google
  This is the network of connections Google uses to identify relevant social search results.
• Constellation – SAP’s Answer to Google Wave
  Constellation is SAP’s contribution to the trend known as collaboration software which attempts to transport the advantages of the Web 2.0 into the enterprise environment.
• Led by Facebook, Twitter, Global Time Spent on Social Media Sites up 82% Year over Year | Nielsen Wire
  According to The Nielsen Company, global* consumers spent more than five and half hours on social networking sites like Facebook and Twitter in December 2009, an 82% increase.
• HTML5 video and codecs
  Recently, Vimeo and YouTube announced that they were moving to support the HTML5 video tag, as DailyMotion did last summer.

Light reading:

• In the Future We’ll All Have Online Reputation Scores
• 7 Reasons Why Developers are Deserting iPhone Apps
• Social Media Upends Super Bowl Advertising Standards
• Facebook Largest Social Network, Twitter Fastest-Growing On The Mobile Web
• Google Twists Knife In IE6, Pulls Support From Docs And Sites

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

We're on the verge of a new era in IT. Web 2.0, E2.0, SOA 2.0: anything 2.0, which I combinedly call IT 2.0

My first IT experiences dating back 25 years, I've noticed that it basically provides humans with machines. Or more accurately, human tasks are slowly replaced by machine tasks where possible

It takes time to turn human tasks into machine tasks, so basically they shouldn't change while being built. They also shouldn't change much after being built. That's why building houses on sand was considered foolish millennia ago already.
It's almost exactly like portrait painting. It's a lot easier doing that when the model sits still, and when done the result looks much more alike if the model doesn't change too much after that

Knowing the how, now the question is: which human tasks can be replaced by machines, or automated?

The closer you come to business, the more humans you'll need. The further you move away from business, the more machines you can use. Basically, business needs people, and machine needs infrastructure

That puts humans on top in the IT foodchain, and machines at the bottom. Although arguably both depend on one another and couldn't live without...

Having said that, there are lots of different properties for humans and machines. Here's a quick model:

Machines serve automation. They are (and must be) rigid, because what runs directly on top is simple and static: great for storing business rules, they handle data very well. They sit in the infrastructure layer
Humans serve people. They are (and must be) flexible, because what they support is complex and dynamic: great for handling business exceptions, they handle information very well. They are part of the business layer

If you compare that to the latest trends, machines perfectly translate to Cloud, and humans to Social

IaaS, Paas and Saas all perfectly fit into the infrastructure layer mentioned above thanks to virtualisation and Utility Computing.
What can be xaaS-ed will be done so in the coming years, and albeit a relatively small slice of the enterprise layer, a large part of its current infrastructure will simply move into the cloud.
And in the years after that, a larger part of the enterprise will become infrastructure, and follow along: Invisible Infostructure is becoming an ever-increasing fact
The enterprise will become more standardised and simple at the bottom, and shrink

Social is 100% people-stuff and fits perfectly into the business layer. Communication (Blogs, Microblogging, Social networking) and Collaboration (Wikis, Social bookmarking, Social news) are tools that need to be plugged into the enterprise. Tools will come and go, be added onto, expanded, shrunk, and the people using them will move along. Process-on-the-fly is here to stay
Organisationally, culturally, politically a lot will change and it will keep changing before more than half of that becomes absorbed by the enterprise, and settles down.
The enterprise will become more complex at the top, and expand

Sketching the future, one can see the structure of IT 2.0 being sandwiched: at the bottom, the floor of the building will slowly be Clouded, while at the same time its ceiling will be Socialised. Two giant movements in opposite directions, much like tectonic plates operate on this earth's crust

Where will the twain meet? What will be there? Will that be crushed, or torn apart?
What will the consequences be for Enterprise IT as we know it, but especially for the future we have in mind for it: E2.0, SOA 2.0, SocialCRM?

I'm looking forward to your answers and ideas! I do foresee quite a challenge

Martijn Linssen is Enterprise Integration Architect within Capgemini. You can find him at martijnlinssen.com

Is not having an identity online or leaving traces online the biggest mistake you can make? Privacy matters, not having any presence online could be great for your privacy, however it could be a disaster for the way other people will see you. What if you are not findable in a search engine, than you have done a good job protecting your privacy (nobody sees any data related to you), however you did a poor job at making sure people are able to get to know you. They might even think that you are hiding something, since it seems you don't have a(n online) history.

The Russians knew that Pravda contained state propaganda so they used other sources to get to the bottom of some news. We all know that resumes are also just propaganda, telling the best things about a specific person that are suitable for a specific job. People like to verify that, they want to know more than just the standard lines on a resume. No they don't need to know your social security number, so you don't have to put that online. However they want to know who you are and what you really did. And these might be the same things as you mention in a resume, however people like to check it at a source that is independent (from their perspective). And with everything searchable nowadays, it gives us a weird feeling when you don't show up in the search results. Somebody who isn't findable has something to hide, or could be a secret agent or isn't even a real person.

Leave some digital footprint, make yourself findable, you might need it in the near future when you want to use a service or need a job.

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

Enterprise Architecture is a well-debated topic. It certainly is an ambitious goal, and encompasses a rather huge area: the enterprise. One could compare it with city architecture, although those folks usually take a bit longer for redesigning and -building entire cities. In IT, almost everything seems to have to fit into a 5- or 10-year roadmap these days

Social is hot as well, if anything we must at least all agree on that.

Both are on their way to make a big move: EA is getting a second chance: ERP+, SOA 2.0, all more or less driven by the larger Web 2.0 movement, whereas Social is getting its first chance. In between the two is SocialCRM

Triggered by the term "Social Darwinism" I was reminded of the fact that survival comes to those who adapt. There is a crucial difference between adapt and adopt. Those who adopt just go out there and get something with a big bang: they wear a new pair of clothes like it's not theirs, but still someone else's. Those who adapt gradually change over time, they change themselves. They will start wearing new shoes, or polish the old ones, and after a while other parts will follow: new trousers, shirt, a tie or not to tie...

Then it struck me that ERP was a huge leap, not just a tiny step. It was an Enterprise-move in disguise: replace all your diverse stuff by all our apparently homogeneous stuff. Or rather: replace all the different bills by just one. BPM intended the same, but never made it through, maybe it wasn't massive enough. SOA never started off small either, it made it to the enterprise level right from the start. Bang!

Is that wise? Isn't architecture all about taking small steps? Chopping up the big elephant in little pieces that can be devoured without choking?

People are now saying that SOA was a good idea, but that the implementation was bad. That's with the benefit of hindsight of course, and just means that you leapt before you looked

Similar moves can be seen in the Social Sphere. Conferences, events, blogs, sites, evangelists and gurus running around naked (i.e. content-free), companies looking for social directors, stories of (sometimes great!) success, Marketing and Sales plunging in there, it gets quite busy sometimes. And it seems like 2010 will now really (really, finally) take off for Social

Remember the dinosaurs. They didn't come into existence overnight. They slightly evolved over a period of time, and that was good. Then, circumstances changed, and they failed to change back.

They adapted when they had to adapt (slow growth), but failed to adopt when they had to adopt. Yeah I know it's tough to shrink by 50% if you're a being, or an organisation. But sometimes it's either that or extintion. So prepare for a bit of partial death while growing

Take it easy. Take an application, a small department, an office. Don't buy licenses to go for the next 10 years, have your dear new friend(s) prove a concept first. Don't look at your neighbour company, because they will assume you're outpacing them already or will outpace them in the near future, and toss some extra money inthere. That will scare you into doing the same, and off you two go creating a Facebook-bubble or something the like

Remember the evolution. It's still going on. Remember Darwin, and natural selection. Adapt. Gradually

Martijn Linssen is Enterprise Integration Architect and Cloudbuster within Capgemini. You can find him at martijnlinssen.com

Listening to communities around you is, if done right, an excellent source of information and innovation. It is also a strategy that is as old as the concept of doing business itself. The only difference being that the communities have increased in size and the sell-by-date of yesterday’s gossip really is yesterday. One way to quickly tap into that collective genius of communities, capture excellent ideas, and grow them for success is to foster bottom-up innovation within or even beyond organizational boundaries with Social Innovation Platforms. In such a platform stakeholders (employees, partners, clients, etc) contribute and collaborate around ideas, present those ideas to an enabled committee (preferably a P&L holding body of experts) request budget, sponsorship, time or goodwill to further their idea. This process scan be facilitated by tooling and communities or, at its bare minimum, via a “dragon’s den”-like set-up. Key here is “social” and the hypothesis is that collaboration, inherently social, is one of the prerequisites for innovation (Franke & Shah, 2003).

As with any open and social community “motivation to participate is key”. As such the success or failure of an attempt at crowd-sourced innovation lies with the organisation’s ability to motivate such participation. Capgemini research shows that the intention to share and to a lesser extent the entrepreneurial mindset of employees (described as the proactive attitude to recognize and act on opportunities to innovate) are excellent indicators of “motivation to participate”. This coincides with McAfee’s (2006) thoughts that the reward of collaboration through communities is one of the reasons that motivates people to share.

The statement I’d like to make here is that engaging communities for innovation goes beyond merely implementing a technological platform for collaboration and waiting for participation. Insight into the motivations of employees to participate in innovation platforms can be translated into recommendations for success. A such we can claim that motivating innovation communities requires attention to the following triangle of success or basic elements of a conducive culture:

1. Mandate of an innovation board (organisational buy-in);
By coupling benefits (intrinsic as well as extrinsic) to participation enjoyment and thus the intention to share as well as entrepreneurship can be stimulated. This show of intent requires mandate of en empowered (P&L holding) body.

2. Communication of intention, progress and success;
Communication entices participation by displaying intent as well as result and benefits derived from participation. This again fosters entrepreneurship as well as the intention to share.

3. Facilitation of the process from ideation to launch.
Ease of participation and a motivating as well as facilitating organisational climate influence intention to participate. This is closely related to choices made in the actual implementation and technological foundation of the innovation platform.

The results of this research are no rocket-science, nor do they represent shocking new discoveries. they do however once again stipulate the explicit need for a thorough focus on the cultural, organizational and communication aspects as the real determinants of success on top of the actual implementation of the platform itself.

Special thanks to Lucas Baarspul for his patience and excellent research produced whilst dealing with the "at times" difficult customer we were.

Research referenced to in this article:
Employees’ motivation to participate in an innovation platform within an organization, Lucas Baarspul, 2009. Research by the Vrije universiteit Amsterdam for Capgemini Netherlands b.v.

Niels van der Zeyst is a Business Technologist at Capgemini. You can follow Niels on Twitter http://twitter.com/zeyst or contact him directly via niels.vander.zeyst@capgemini.com.

If we take a look at classic Business Intelligence we find that it is focused on using company data to report and analyze the current (or past) performance of the organization (lag). However, the Return-On-Intelligence (ROI) increases as organizations use this data to take a proactive approach in their decision making (lead). A good performance management framework therefore often consists of both lead and lag measures.

Let’s break down the definition of CPM. Firstly, we take a look at “relevant methods”. This refers to such methods as the Business Balanced Scorecard (Kaplan & Norton), Lean or Six Sigma. Secondly, it’s about “processes”, or in other words a performance improvement process. The third element is “Metrics and systems”. Another, widely accepted, name for metrics can be Key Performance Indicator or KPI. The system to support this would be Datawarehousing & Business Intelligence. But all these afore mentioned elements are used to “measure and manage business performance”. And this means that CPM is focused on delivering a system with set of Key Performance Indicators to measure (by definition) past performance and use this to manage (or plan) future business performance.

So how is this different form the new number one on the hype cycle chart: Analytics? The main difference would be that analytics focuses not so much on measuring and managing but on analyzing data to gain insights and real understanding of (hidden) business performance. It is the next step in the evolution of Information Management. With CPM we can answer such questions as what happened and where (which we really need to know) but with Analytics we begin to understand the why. It will open up the road to not only making better decisions but maybe even the best decision.