Blockchain – enabling true digital transformation

Blockchain will significantly change how we hold and transmit items of value. The business process can finally be designed from the ground up as a digital process – truly transformed. The record of choice for the last 100+ years has been paper. Even when you scan a record, if the paper exist, it is the legal record.

We have birth and death certificates, laws, deeds, bank statements and even money (bills) on paper. The problem is we are becoming a digital society and paper is hugely inefficient. In addition, the processes for handling paper have stayed in place even with digital systems and are highly error prone. How likely is it that an error occurs upon copying or reading a document. Blockchain offers the opportunity for  processes to become 100% digital, secure, and low friction from birth to destruction.

The simplest definition of a blockchain is a digital ledger that is not terribly different from an old fashioned paper accounting ledger. A well implemented blockchain has 3+1 key characteristics. It is immutable meaning once a transaction is entered, it can’t be removed or altered. It is sequential in that each transaction is tied to the one before it and after it. It has consensus based peer nodes that can be distributed. I’ll add a fourth for a “well implemented” blockchain, that it has inherent security with multiple levels and is highly resistant to attack.

A blockchain is not Bitcoin or any single crypto-currency. Crypto-currencies like Bitcoin do run on blockchain technology. The data entered in the ledger for crypto-currency are financial transactions representing value. What fascinates me, and is the subject of this blog, is what else can you do with a Blockchain.

6310306480_6309d1438a_b

In 3 recent experiences with obtaining a mortgages, I’ve had a 10%, 50%, and 90% paper based process. I’ll exclude the closing process which is still done on paper thanks to the government being nearly 100% paper based.

Bank 1 was 90% paper based. Everything went to the branch office as paper which they put in a box and shipped to the home office where it was processesed. Only the communication via e-mail was electronic.

Bank 2 was about 50% paper based. They allowed us to submit our documents via an upload, most documents were e-signed, and a few that presumably the government required wet-ink signed, we’d print, sign, and then upload them.

Bank 3, actually a mortgage service, never gave us a piece of paper, but I’d argue it was still only 90% digital. Someone was still transcribing from the uploaded images into the lender’s databases. Even if all of the paper was eliminated, Bank 3 still was working workflow designed for paper. It took limited advantage of the fact that everything was now digitized.

Screen Shot 2016-08-28 at 10.50.35 PM

Blockchain will change the above mortgage process. There will be no transcription and therefore less chances of error. Hypothetically, you’ll upload your information from a digital store on blockchain of IDs which will include multiple biometric authentication methods to confirm it’s really you. You’ll permission your lender to do research on your credit worthiness in various financial blockchains. It may even eliminate the need for the credit scores and credit bureaus as credit data can be gathered directly and relatively quickly (more on that later). At the same time, they will review your deed and other documents with the government making sure you are lien free.

All of the approvals, audits, and additional documents will be kept in the lending agency’s blockchain, but can link with permissions to other blockchain’s or simply make copies with reference to the source. Finally, your signatures will cause the down payment to be transferred along with the signatures of everyone involved from the bank, regulators, attorneys, auditors, county and state tax authorities, county court records, insurance agencies, buyers, and sellers. In theory, from discussion of the mortgage to the completion of the mortgage a day or few day process.

The biggest issue with blockchains, besides they are new and we are just starting to build applications for them, is that they are slow in terms of computer transactions. The slowness is mostly due to the consensus element. For all the nodes (computers) to agree it is valid entry, it can take up to a few minutes. While this is huge leap forward in terms of recording a legal records which can now take weeks or months, it far is too slow for sub-second transactions like purchasing on the internet or recording an entry at help desk. So for now, it is best applied to large block type transactions of higher value which fit the characteristics of blockchains.

Here are a few areas where blockchains are a natural:

  • Medical records (individual, hospital, doctor, etc.)
  • Government documents (deeds, judgments, laws, titles, licenses, etc.)
  • Financial documents (bank ledgers, investments, statements, etc.)
  • Supply Chains (farm to fork, inspections, transportation, etc.)

Where else might blockchains fit? What other technologies like AI might be integrated?

If you like to learn more about how you can build on the blockchain, IBM provides FREE tutorials on the Hyperledger, an open sourced blockchain.

 

Advertisements

If IBM Watson (AI) is so smart, why isn’t Watson able tell IBM how to make billions dollars?

“If IBM Watson (AI) is so smart, why isn’t Watson able to tell IBM how to make billions dollars? Can’t you just ask Watson how to make more money?” It was an earnest question from a skeptical client. We all want an oracle we can ask.

I answered “IBM Watson can’t just know how to make money. It has to be taught first by humans. A person must teach Watson the knowledge and then Watson can expand on it.” The simple answer is IBM Watson is similar to all Artificial Intelligence (AI) tools. It is just a tool and not an all-seeing, all-knowing oracle. Buying a chef’s knife does not make me a chef. The old saying is “a fool with a tool is still a fool.” Watson, or any AI, can’t just imagine ideas, create new solutions, or create new solutions. While it isn’t an oracle, it is highly useful tool.

The real purpose of this tool labeled as Artificial Intelligence, Cognitive Intelligence, or Assistive Intelligence is to provide computers with more human like interactions and understanding. Reading, writing, speaking, listening, seeing, and feeling are very human experiences. We define our world this way via our senses and sense of self being. At IBM, we have Watson focus more on the cognitive (thinking and feeling like a human) and being more supportive via assistive intelligence. The cognitive capability provides the computer a better and more natural way to move, communicate, interact, and learn in our human focused world.

A good example is Watson Cancer Diagnostics. It first was taught how to diagnose and treat cancer. The cognitive capabilities allowed it to speak, listen, write, and read both questions and answers. I even learned to read radiographs (visual). That gave the solution a baseline capability. Now it is moving onward by reading printed journals. We as humans think of it as nothing to extract information out of reading a book, but this is unstructured data which only a few years ago, computers couldn’t understand. Now with Watson, they can. Today Watson Cancer Diagnostics can work with doctors and suggest treatments, but ultimately, we still rely on the doctor to make the final diagnosis and treatment.

Water is the universal solvent. Humans are the universal problem solver. Computers are wonderful tools to enable humans. By adding cognitive capabilities, computers become even better and easier to use tools to assist us in shaping our world and hopefully for better.

 

Move, Adapt, or Die

Change is eternal in life, nature, business, and technology and you only have 3 options:  1) Adapt; 2) Move, or 3) Die.  I learned this truism in my 7th grade from my social studies class regarding animals response to ecological change, but the same is true for changes in our business environment.  The technology environment has forever been changed by CLOUD (IaaS, PaaS, and SaaS).  The software business and the systems integration (SI) will never be the same and is now presented with 3 simple options: 1) Adapt; 2) Move, or 3) Die.

As humans, especially business people, engineers, etc. who populate a lot of technology field, we believe we can overcome or stem the tide.  While this may work for short term or against small storms of change, it will not defeat real, substantial change any more than you can push back on walls of water from hurricanes.

IBM recognizes the power and importance of Cloud, even if it got off to slow start. Look at the emphasis. Less than 10% of IBM’s revenue is now from hardware. At the same time, everything from IBM is now on the cloud. IBM is even beating back its latest foe – Amazon Web Services (AWS). IBM Beats Amazon In 12-Month Cloud Revenue, $15.1 Billion To $14.5 Billion.

SAP has made a massive shift around SaaS and is adapting.  In 2013, Jon Reed, noted that even SAP executives would love to go on selling traditional on-premise perpetual licenses when he paraphrases the executive with ‘Hey, if we could continue to sell software to customers the way we’ve sold it to them for the last 40 years, we would. But they want new options.’  (more from Jon Reed’s Diginomica blog). Fast forward to 2016 and about 80% of SAP’s revenue is from 4 acquired SaaS products: SuccessFactors, Fieldglass, Concur, and Ariba. If SAP could figure out S/4 HANA cloud, they might even become a dominant SaaS ERP player.

Cloud and specifically SaaS to the software industry is a category 5 hurricane force of change driving a wall of water.  Remember when virtualization was only for non-proction. Now, most systems depend on virtualization.

Moving and adapting take time. So while almost everything will go cloud, it will take time. It will have to make IT and financial sense to move. The argument that some applications will not run well on the cloud will be a moot point when they are rewritten for the cloud.

The hurricane of cloud  in all forms is coming here. What are you doing to make sure your ready to move or adapt (and not die).

 

Please STOP using meaningless terms for cloud like Private, Public, and Hybrid

There are 2 dimensions that have meaning when discussing cloud solutions and the terms public, private, and hybrid contains too many overlaps and ambiguity.  Is a cloud private if it is hosted?  Is a cloud public because I access it over the internet and does that mean my corporate data center accessed via VPN is public?  Worse, the term Hybrid Cloud gets bounced around so many different ways that is no longer relevant at all.   I could have SAP ERP and SuccessFactors  or SAP ERP production in a corporate data center and the non-production SAP ERP systems on a IaaS cloud provider such as IBM’s SmartCloud IaaS  or it could mean I do some ERP functions on SAP ERP on premise and some using SAP Business-by-Design (BbyD) or on NetSuite ERP.   In the end, it only means  is I’m using more than one type of solution.

There are meaningful dimensions to describing cloud solutions.  The two (2) dimensions that matter are: 1) location, and 2) separation.

First is location.  Where is the solution residing?  Is it on my premise, site or facility that I own or at least consider part of my corporate network of locations.  Alternatively, is it away from the bulk of my IT assets such  that I need a WAN to access it.  For clients with highly distributed data centers this becomes a moot point since everything connects over the WAN; however, most clients have consolidated their corporate application and data centers into just a few locations.  IBM runs its corporate business in just a few data centers with SAP in just 2 of them globally.

Second is separation.  What separates the resources.  Are the solution resources separated by physical boundaries such as server, application, or database or is the solution separated by layers of software?

The trend is clearly towards SaaS where location is off premise and all the infrastructure and application components of the solution are software separated.  In a SaaS solution, it is clear you are using the SaaS providers data center of choice and not your own.  You also are accepting that the secured division of servers, network, and storage.  Even more importantly, you are accepting that your data in flight (within the application) and at rest is kept secured and separated from others including your competitor.  I have seen numerous cases where direct competitors use the same SaaS solution.  In fact, most SaaS providers count on competitors using their application to scale since you can’t build a SaaS business on single client.  Clearly, we do believe in software separation has come of age.

Software divided applications and infrastructure is becoming a the rule.  If you want to take the software divided and secured environment on premise, IBM calls it Software Defined Environment (SDE) ().  Another major player, VMware, calls it Software Defined Data Center (SDDC).  Regardless, each is an attempt to virtualize the infrastructure for more effective use of all assets.  This is good for both cost savings and for agility.  Deploying virtual infrastructure is far faster than physical.  Often clients think the value of the business case is in the cost savings, but ultimately it is found in the agility that translate into real application and business value.

So, next time someone comes to you with a hosted semi-private cloud infrastructure offering with hybrid capabilities, just ask them 2 questions.  Where is the solution residing?  What is separating the infrastructure and applications?  Concise answers will reveal a lot about the solution and you’ll have more time to do something beautiful like grow your hybrid tea roses and find PEACE.

More acceleration for your on-premise ERP program with SaaS

Rather than considering SaaS the enemy of on-premise ERP, consider how you can leverage its capabilities to consolidate, optimize, and simplify your on-premise ERP systems to achieve a better, faster, more agile result.  On-premise ERP  is not going away tomorrow, at least if you run it well and provide the required agility to the business and SaaS can help.  The key is providing the right services levels across the entire environment.

In my last blog, 2-tier ERP: A cure for the smaller markets in a global implementation, I discussed how you can use a SaaS based ERP implementation to eliminate some of complexity of the implementing simpler, smaller markets.  The focus was geographic or unit based.  Similar logic can be applied to functionality.  Some Line-of-Business (LOB) applications and/ Human Capital Management (HCM) / Human Resources (HR) functions can also be pulled into SaaS.  The result is even more acceleration of your overall program.

Most of my clients are either using or reviewing the use of SAP SuccessFactors, SAP Ariba, and SalesForce as SaaS based LOB’s.  These 3 SaaS solutions show up repetitively at many SAP clients.  I am well aware SAP has CRM and even a CRM RDS (Rapid Deployment Solution) on cloud, including IBM’s SmartCloud and even CRM capability in Business-ByDesign, but SalesForce is dominant in the market and needs to be considered.  Clearly there all alternatives to these 3 SaaS solutions in the market.  I use them as examples and your company needs be responsible and do a comprehensive review of each area to find the exact solutions that best fit your company.  I’ll simply use these as common examples.

The idea is if you can remove the scope of configuring SRM with Ariba, most HR / HCM scope with SuccessFactors, and CRM scope with SalesForce, the reduction in scope in the core and plus making them parallel projects can enable the overall implementation to move far faster and introduce some heavily requested mobile capability.

erp - using SaaS functions

In addition, by using SaaS based products you can potentially lower costs of procurement, implementation, and support.  You definitely can accelerate the roll-out of these functions and bring significant mobile capability to business in these areas which might help your business case by bringing benefits earlier.  These 3 areas are especially important since the touch so many individuals with mobile roles.

By design, every SaaS program I’ve seen is heavily mobile enabled.  Mobile and cloud are ideally suited for each other.  The more recent thought process of agility and velocity drives a simpler and more targeted design for most SaaS solutions.  The SaaS thought process better fits the minimalist mobile screens than the idea of highly optimized processes found in most core on-premise ERP systems.  Cloud serves mobile well since it is equidistant to all devices.  Mobile devices are not clustered like terminals around headquarters based system which up until recent was the assumption for on-premise ERP.

Even if the SaaS implementation is a wash on cost, the acceleration of delivery and the enhanced mobile capabilities may push the business case over the goal line.  Keep in mind that the mobile applications are native to most SaaS applications so you don’t have to build up a support staff to maintain the mobile interfaces like with many ERP add-on products.  They are as native as browser support is in SAP ERP.  You still will need to manage devices and may even want to build, but the native mobile capability will lessen your IT support burden.

SaaS is not a panacea.  For companies who require extremely high complexity or significant optimization of processes, it may not meet their requirements.  If your company is sensitive to OpEx over CapEx (utilities generally prefer CapEx for IT) then SaaS may not be a good solution.  Finally, SaaS applications require integration, most likely you require some optimization (custom functions), and require good project management, organization change, communication, and training which is not significantly different with SaaS than with on-premise based implementations.  Maybe a simpler program can demand less of these soft skill deliverables, but it is not the “SaaS” that changes the effort.

In your next transformation program you should consider the use of SaaS based applications to remove scope, increase velocity and agility, reduce the overall program timeline, accelerate benefits, and potentially lower total costs.

In my next blog, I’ll examine how this idea can be applied to an existing SAP landscape requiring renovation, optimization, or simplification.

2-tier ERP: A cure for the smaller markets in a global implementation

Many companies over-engineer, over-build, and spend too much for ERP as they begin to implement smaller markets where the needs are relatively simple when they try to shoehorn them into the larger global ERP system.  Even after implementation, the smaller “units” often find it difficult to get their requirements met as they account for such a small percentage (%) of revenue.  One of the biggest hassles in SAP is security and separation of duty (SOD) which often requires smaller offices with just a few workers to have special profiles, multiple login’s, or some special process to fit into the bigger office process.  There needs to be a better way to meet the requirements of highly optimized larger markets with large work forces and smaller, simpler, and more fickle markets with smaller work forces.  A 2-tier ERP solution might be the cure.

Up to now, companies have spent billions on  ERP implementations resulting in significant results.  Specifically for SAP, many of the fortune 100 companies I work with credit some portion of their ability to keep up, survive, and some cases surpass their competitors to their SAP systems.  The most successful implement SAP using standardized processes, strong governance, and fewer, and fewer instances.  Companies with lots of instances often ask me what is the right number of instances.  It is the fewest number of instances which can meet your business requirements.  Not 1, 2, or any specific number, but the fewest.  Each company has to look at its own situation, goals, and markets; however, I believe implementing a cloud based ERP (SaaS) such as Business ByDesign (https://www54.sap.com/pc/tech/cloud/software/business-management-bydesign/overview/index.html) can make implementing or getting to “fewer” much more possible and ultimately better meet the requirements of all parties unilaterally.

In the examples below, the imaginary company has about 80 divisions, units, or countries (depends on how the company organizes and implements) it wants to implement.  A rough cut of revenue shows that 65% resides in top 10 and additional 25% in next group of 10 (11 – 20).  The last group of 60 only account for about 10% of revenue.  While this is fictional, it is a composite many of my experiences in the real world.  We often spend as much, or more, getting the last 60 units into core instance.

All in one ERP model
All in one ERP model

If we recognize that the goal of the fewer or even a global single instance is not simply being on one system, but to have consistent, audit-able processes globally, a new option opens up using a 2-tier ERP model.  Bottom line is in many of these smaller units, often countries, the objective is really to make sure the financial results are valid and that ultimately the CFO can count on them when he reports out to Wall Street.  Getting everything into single SAP system was the best way, and in some scenarios still may be the best way, but it might pay to look at a SaaS based ERP solution as shown below.

Two Tier (2-tier) ERP model
Two Tier (2-tier) ERP model

Often I’m asked, why not just take one of our ERP systems and make it the “light” ERP system and we can even place it on the cloud (IaaS/PaaS).  It does work, but it misses many of the advantages of moving to SaaS.  It is a good option if those other units require lots of optimization.  In contrast the SaaS option will provide a more generic solution focused at smaller organizations with shorter implementation periods, mobile enabled GUI, and pricing by user which may match the more volatile small unit markets where staffing may quickly shift up or down.  Finally, if you are already on SAP ERP, there are significant integration between SAP ERP and Busines ByDesign pre-built with new ones being rolled out in future versions.

I will continue to encourage clients to move to the fewest number of instances which can meet their business requirements.  Adding a SaaS based ERP system such as Business ByDesign could make that journey even simpler and faster.

SAP HANA MCOD – What I really want for my data center

The real SAP game changer will be when I have one (1) HANA DB for all my production applications.  I want single, giant in-memory DB where my ECC, BW, CRM, PLM, SCM, BOBJ, etc. all consume the same data.  I want a row  view for the OLTP ECC-like applications and column view for OLAP BW-like applications.  It would look like the picture below.

sap hana mcod system
What we really need from SAP! The SAP HANA MCOD system.

Right now, I can’t really recommend using HANA on anything but OLAP based applications.  In the future, when we can do the analytic transformations in memory without silly exports, extractors, DSO’s and the like, we will really have a very* different scenario.  For now, the cost of the HANA license and risk of losing transactions only committed to memory is not justifiable.

In this new vision with MCOD, there will be two (2) key issues.  First, how do we support MCOD.  I’ve seen MCOD come and go since 1993 several times. Each time, it was easy to build and impossible to support.  The overlapping requirements became overwhelming. Second, HANA will need a data aging architecture which can age data out of main memory to some slightly slower memory or device.

IBM is working on some important technology, Phase Change Memory, that will be of great value (http://www.zurich.ibm.com/sto/memory/).   It may provide the near DRAM speeds while being cost effective and non-volatile.  Maybe IBM will build out series of servers specifically designed to run in-memory databases such as HANA with massive DRAM and massive PCM capacities.  PCM could then provide the roll-back logs and more at near DRAM speeds. PCM won’t solve the MCOD and data aging problems, but at least the risk of running rapidly transacting OLTP systems would go to near zero and certainly lower than that of even today’s highly cached disk writing databases.

It is going to be a fun watching HANA make it from infancy to toddler-hood.  I wonder how fast she’ll mature.

* Mark Twain said every time a writer was tempted to use “very” in a sentence, they should use the word “damn” and then the editor would strike the word and the sentence would read as it should.