So if you’re at SAPPHIRE NOW / TechEd Madrid…

Posted on by

smiling coffee cup

… and you spot me either rushing from session to session or in deep conversation with someone, I urge you to interrupt me for a chat. You’ll recognise me by the “@PIXELBASE” Twitter handle on my SAP Mentor shirt.

Independent SAP Development Consultants like myself can be less influenced by the latest trend and fashion, because our work is very often based on current customer project requirements. I therefore tend to be more pro customer-side, trying to “keep it real” and end-user relevant. Having said that, it’s also important to get a glimpse of the future and accustom yourself with upcoming products. That’s one of the reasons why we’re all going to TechEd.

One more word with regards to SAP Mentors: We’re a groovy bunch, but just because we’re Mentors doesn’t mean we know everything. SAP Land is a vast space and not one single person can claim to have the complete knowledge. And to be honest, we don’t have to, because we are a passionate, open, collaborative and extremely communicative team. Believe you me, we can talk for hours about SAP stuff.

If you have a question about Mentors, our initiatives or you even want to chat about something that bugs you, then let us know. We can be quite critical about SAP and its products, too and we’d love to hear your constructive thoughts.

And most of all…. HAVE A GREAT CONFERENCE !

SAP Development: having the guts to be great

Posted on by

Some of you might have seen Hugh McLeod’s picture about producing something “amazing”.

As it happens, today I had a work discussion that touched on just that. We were faced with the choice between something that ticks the “timescale” and “achievement” boxes and something that ticks the “appealing” and “users will love it” boxes. Suffice to say what the obvious business decision was… once again, Quality was Job One.

I see this at a lot of SAP sites. The implementation team knows that users are not particularly happy with the system, but everyone seems to be getting their work done, so why do things different? The SAP team therefore focusses on the measurable part, the quality. They might even say: “Hey, SAP is standard software after all. If you want to have fun, install Garageband on your own machine at home!”. I used to say that, too. But not anymore. Because things have moved on.

So here are some key points to all of those who oversee developments and have the power to decide whether a development should do same-old-same-old or push some boundaries:

  • trust your senior developers, let them “loose” every now and then
  • use prototyping to explore new areas once in a while
  • not everything has to be done in SAP GUI (or downloadable into Excel, for that matter)
  • send your team to events such as TechEd
  • have the guts to defend your team’s efforts and ideas in front of your superiors
If you have been affected by the points raised above then please feel free to come and chat to me about it at SAP TechEd Madrid next week.

interesting conversation on SAP Outsourcing

Posted on by

Fellow SAP Mentor Vijay started an interesting post series on Offshoring and Outsourcing over on his blog. His first edition deals with a little bit of SAP Offshoring history. A trip down memory lane so to speak. Vijay provides some very interesting insights into an industry that has seen a lot of growth in recent years, but is also slated for not always providing best value for money.

Nowadays outsourcing of SAP resources has become commonplace. Standards and SLAs have improved the overall service provided. However I have yet to speak to a client who wholeheartedly loves it. Most of them do it, driven by cost pressures, not conviction or deep belief in its merits.

As mentioned in my comments, I compare it to the big mains gas or water utilities that bring in expertise to deliver a service to your street or door. Skilled in-house teams or freelance resources then get it into your home.

It’s not what outsourcers will tell you, but it’s what my experience has shown me.

I’m looking forward to the next instalments.

Looking back at your ABAP code in anger ?

Posted on by

An interesting conversation was sparked off by this tweet today:

 

 

 

 

 

My response to this was:

 if you work in a department that has time to revisit code then somethings wrong, too. I rarely get that opportunity.

 

To round it all off here was Ethan Jewett’s response:

Disagree. Something is very very right in that case. Question is why it never happens in SAP space.

 

Within Enterprise Software, one important thing to keep in mind is the purpose of the project you’re working on. A lot of my work focusses on Enhancements and Exits in standard SAP modules, another sizeable chunk is in bespoke SAP developments. Whilst the latter tend to be rightfully graced with more design thinking, Enhancements and Exits are very often “one shots”. A functional consultant and /or myself perform analysis and risk impact, implement the enhancement/exit, develop the business logic and test it. Once the work is done and does the job as intended, everyone is happy.

 

Bigger fish to fry?

Now, some time down the line the code for this enhancement might become dated. This can happen if syntax, tooling or standards have improved. But unless there is a pressing business reason to change the coding, everything is kept as it is. More than often there are good reasons for this: Additional development overhead, new developments, upgrades and the ever-popular regression testing are only a few things that spring to my mind. A keen developer might look back at his code in anger, but let’s not forget that code stability is also important in business. What if your code might be up to scratch with the latest release, but fails to create the invoices it is intended to do?

Does it mean that ABAP development leads should not -even for smaller enhancements- preach things such as OO-thinking, reusability, peer reviews and unit testing? Far from it. In times of shrinking budgets and shorter implementation times it is even more important to apply more design thinking, improve your dev teams skills base and promote better team communication (because that’s what it often boils down to).

 

on blogging

Posted on by

There’s an interesting blog post by Hugh McLeod aka Gapingvoid, announcing that henceforth he will stop using Twitter and Facebook. His explanations about “taking a stand” (see in the comments) got me thinking.

 

Twitter, Facebook and even Blogging have become a very crowded space. I get what Hugh says about reclaiming blogging – it remains an area where you can put your own stamp on something, on your own site. To a large degree, that’s why I always blogged very little on SDN.

 

Having said that, even attempts to create something new can easily be copied and claimed by the pros, like TWIS. It was a commented link-list and I didn’t find very satisfying over time. Within reason, it gave me popularity and clicks, yes, but it was not my own content, really. So much for the sour grapes…

 

Nevertheless blogging can still give you that sovereignty that Hugh is talking about. So here’s to more blogging, new ideas and sovereignty on Pixelbase.co.uk !