The article Of Bulls And Bears (Von Bullen und Bären) by Peter Hill is written with German precision, brutal honesty, and trademark humor (so subtle that you don’t recognize a joke until it suddenly hits you 3 sentences later). This expose talks about the different types of SAP customers:

• the “powerful and well organized” bulls, large global corporations that run a tight ship;
• the bears that “roar – and lose sight of the project”.

Peter’s description of the bears is chillingly accurate:

[…]those corporations that – out of sheer company politics and preoccupation with themselves – often lose sight of the real work on the necessary changes. Huge sums of money are sometimes spent just to end up with fewer functions and automations than before.

I bet every seasoned SAP consultant has encountered those projects where whoever screams the loudest gets their way, even if it adds no value for the business at large. Yikes.

Peter also offers solid advice for the consultants. The bull “can be tamed with a lot of patience and brain power” and the bear, “requires a thick skin and a lot of caution”. Power up your trusted translator and read the article in its entirety to avoid getting mauled on your next SAP project! JP

Check out more from this issue!

SAP turns 50 this year. Stuart Browne over at ERP Today has a great piece on what’s changed over the years, and why – dissimilar to MTV – SAP’s aging has been not-so-graceful in some areas.

In the past, solutions that offered great integration got the most attention from businesses. This was SAP’s kingmaking feature from the start – bundle business processes together and integrate them. Just like MTV with artists aiming for music videos as key to their image, consulting companies put SAP at the front of their partnership plays, creating an entire ecosystem.

But time marches on. MTV adapted from solely focused on music videos to creating other forms of viewer content. Browne rightly points out the best example of this: Beavis and Butt-Head. And then he (convincingly) argues that SAP hasn’t been able to reinvent itself similarly. Monolithic ERP has meant sacrificing the agility of some parts for the sake of moving things “at the pace of the slowest functions”.

Lots to chew on in this piece. I am also in agreement with two things: companies seem less apt to choose huge monoliths and instead want to break things up into best-of-breed, and the skills shortage in SAP consultants doesn’t help. I’ll add that orgs who take hyperscaler capabilities seriously and architect their networks of solutions around elastic platform resources will be best enabled to overcome challenges quickly. PM

In my other nerd life at Bowdark Consulting, we podcasted with Shane Young, a ninja master of Microsoft Power Platform, about democratizing the low-code/no-code space for everyone. That episode primed my eyes for an ERP Software Blog piece making some more distinctions about democratization in enterprise IT. 

(Yes – the linked piece above is sponsored. Sponsorship doesn’t automatically render something false, and this sponsor is beating a drum whose rhythm I happen to like.)

There’s a bifurcation of democratization processes happening right now. First is data democratization. Think about every time in the last two decades you’ve heard the term “self-service BI” – that’s the thing here. “Data democratization is the idea of making sure end users have the skills and tools to access, analyze, report on, and use data without IT’s involvement.”

Then there’s what this piece calls “technology democratization”, where IT enables business users by allowing them to BUILD the apps they need: “they want the power to develop solutions that help them do their jobs better-from achieving deeper insights to advancing workflows.” Essentially, we’re talking about low-code/no-code platforms here. 

I have known so many smart, business-savvy people who also think deeply about tech and the processes they perform on the job. They have the right mindset to be developers, even if they’ve never bothered to learn how to write code. Now is the right time to get these people involved in building their own solutions, and IT doesn’t have to hand over the keys to all the systems – they just have to think about providing platforms. PM

See more at this story’s original home.

Many IT projects are poisoned by the “give us all the detailed requirements and we will build exactly that, whether it makes sense or not” mindset. The antidote is the product-minded developer (or engineer). As Gergely Orosz describes them, they want:

[…]to understand why decisions are made, how people use the product, and love to be involved in making product decisions.

Gergely Orosz, “The Product-Minded Software Engineer”

In the SAP world, product-mindedness comes with some special challenges because SAP standard is part of our product. Typically, SAP developers need to work with it to avoid another ZSAP or work against it to implement something the business users really need but SAP just doesn’t deliver. I think curiosity and not being afraid to ask “why?” is the key to not confusing one with another.

Also, in too many projects SAP developers are separated from the consumers of their product farther than from Kevin Bacon. This is a sure way for your product to end up like the tire swing meme. Want to avoid that? Then hire, support, and promote the product-minded developers. And let them ask the right questions to the right people. JP

See more at this story’s original home.

I noted a story from Enterprise Times on skills. The title calls out “8 skills you must consider when hiring technical staff” – but in reality the piece talks about 2 separate skills concepts. 

It leads off noting that digital transformation – for all the BS that term still carries – has focused on cloud, AI, and (for SAP teams) S/4HANA. By focusing in on those skills, legacy SAP teams who focus on keeping the lights on (here in the States, it feels like most SAP teams focus exclusively on that) lose out on the new skills that drive S/4. ASUG found that 26% of member companies see next-gen SAP skills as their biggest SAP challenges. UKISUG found that more than half of member companies see other next-gen skill gaps as slowing their S/4 adoption. 

Scary numbers established!

But then the focus shifts to general-purpose skills that hiring managers should look for in new candidates, like integrity, discipline, collaboration, and so on. I completely agree with all 8 of the skills that the piece lays out for new hires – but it’s a bit tangential to the first topic of the piece. In other words, it’s great that you’ll find people with discipline…but no amount of integrity will make an ABAPer understand CDS. The skill gap will persist, at least in the short term of the S/4HANA upgrade deadline. 

So my add-on advice is this: large companies, service providers, and SAP team managers, your tech team isn’t going to magically show up one day with the new skills they need – they deserve the right time and tools to improve. Sometimes keeping the lights on means learning how to operate a new light switch. PM

See more at this story’s original home.

Seasoned developers, like myself, tend to reminisce about the “old days” (about 5 years ago) and either admire or grumble about the progress made since. In his article How is computer programming different today than 20 years ago? ex-Microsofter Sedat Kapanoğlu makes interesting observations on how programming changed in the last two decades.

Some items on his list, such as garbage collection, won’t ring a bell to SAP developers, but I found many of his observations quite relevant:

• “Language tooling is richer today.” Probably less so for SAP proprietary languages but still, just 10 years ago our choice of tooling was like in the famous Henry Ford quote, “any color as long as it’s black”.
• “IDEs and the programming languages are getting more and more distant from each other.” But, of course, we are still having debates on how SAP GUI is better than Eclipse. Time to move on, folks.
• “Unit testing has emerged as a hype and like every useful thing, its benefits were overestimated and it has inevitably turned into a religion.” This perfectly reflects my own POV on unit testing. Debating with its adepts is definitely as pointless as trying to talk someone out of their religion.

Bring on the angry letters! JP

Don’t miss our latest issue!

There’s a developer community challenge for SAP AppGyver that just closed its entry period. I used to get fired up to go try out community challenges (even if I didn’t usually take the step of submitting the entry…it’s more like I just wanted to try the thing out) – but these days I guess I’m feeling my age more. I just go look at submissions and cast judgment from afar. 

So here are some interesting submissions I’ve seen!

• Michelle Crapo is going to put her low-code skepticism to the test. I’m waiting to see what she has to say, since I hear lots of similar sentiment out here in the wild west.
• Petr Kursin went to a lot of effort to make lots of different features in his app. For a try-it-out contest, I thought it was quite good at showcasing a lot of different features.
• Kai Niklas contributed a food alert app. Of note here is that he thought about going further into the notifications side of AppGyver’s capabilities, but to his eyes the push notifications feature (which as of now runs through Firebase) didn’t quite fit the spirit (or his skillset) of low-code. 

I’m a huge fanboy of Firebase, by the way. I’m sure SAP has plans to roll the notifications feature together more tightly with BTP’s Mobile Services push, but until that happens Firebase ain’t that bad a place to be. 

I watch AppGyver with curiosity, since the acquisition isn’t even two years old yet and clearly SAP has a lot to do on their AppGyver roadmap. Low-code and no-code seem to have roughly two directions lately: general-purpose platforms that don’t care what your base business systems are, like Appian and Microsoft Power Platform, and platforms that get delivered with specific ERP-sized applications, like AppGyver (or what it will be) and ServiceNow’s App Engine. Low-code and fast app delivery is so clearly part of the future-becoming-now that it’s hard to pull my eyes away from developments in this space. PM

Don’t miss our latest issue!

Jelena and I talked to Graham Robinson – or Robbo, to those in the know – about a plethora of interesting subjects. Community keeps coming back up, like it did with Jamie Langskov, but we also dove into APIs, how to be rebels, and the impact of Antarctic journeys on one’s soul.

Be sure to subscribe on your favorite podcatcher for more!

After taking a look at Accenture’s SOAR and Infosys’ ERPaaS, I’m turning my RISE with SAP eyes to IBM. They’ve got a service offering called BREAKTHROUGH with IBM for RISE with SAP – which to my eyes verges on silly. I can’t help but think of additional clauses, like:

• BREAKTHROUGH with IBM for RISE with SAP for SENIORS with ARTHRITIS
• BREAKTHROUGH with IBM for RISE with SAP at NOON on CHRISTMAS
• TOUCHSTONE PICTURES presents BREAKTHROUGH with IBM for RISE with SAP featuring STEVE MARTIN with JAMES MASON as DRACULA

Anyway. Enough horsing around. 

Funny name stuff aside, I actually found that from the website copy and videos I understood IBM’s offering better than either Accenture or Infosys. It shares the digital transformation-speak, advisory services plugs, and industry-specific templates that the others have. But as a company, IBM can offer an additional piece those other two cannot: its own cloud infrastructure. “BREAKTHROUGH with IBM for RISE with SAP, Premium Supplier Option” makes use of IBM’s Cloud IaaS as the infrastructure layer for all the other pieces. As a one-stop shop, it seems like an attractive option. 

They’ve also given what seems to be quite a bit of thought to the move-to-S/4 process. There are (at least) two styles of upgrade/movement they offer, with “IBM Rapid Move for SAP S/4HANA” seeming to focus on more complex upgrades, and “IBM Accelerated Move” looking like the focus is on simplified, t-shirt sized simpler upgrades. 

I’m intrigued by all this. Not because of curiosity about huge consulting firms’ offerings, but because somewhere down the line, after all the upgrade dust has settled, everyone’s going to have to get back to the business of innovating. Innovation cycle speed after the S/4 migration is done will be the true test of any S/4HANA project. PM

Don’t miss our latest issue!