_
RobertoLofaro.com - Knowledge Portal - human-generated content
Change, with and without technology
for updates on publications, follow @robertolofaro on Instagram or @changerulebook on Twitter, you can also support on Patreon or subscribe on YouTube


_

You are here: Home > Diritto di Voto / EU, Italy, Turin > #digital #transformation in #Italy : the #electronic #invoicing and #broadband cases

Viewed 5265 times | words: 3724
Published on 2018-11-28 20:43:35 | words: 3724



subtitle: and the difference between dreams, ideas, projects, execution, and benefits realization.

I promised few days ago that I was going to post a follow-up article about the Italian side of my recent post on transitioning business.

Well, over the last couple of weeks, beside my other knowledge updates and upgrades (e.g. on languages, SAP, data science), I also added something about Italian tax rules.

I did a review of Italian rules on e-invoicing last summer in preparation for a project that never started, as an update to something on dematerialization that I followed in Italy approximately a decade ago, also if my first real project on dematerialization of legal/tax documents was in the early 1990s.

Bear with me for a couple of minutes while I dive into the past.

Early 1990s, a time when "optical" meant "laserdisc" or one of its variants (https://en.wikipedia.org/wiki/LaserDisc).

The concept was: at a time when each store around the country for a large chain was required to have a local paper-based employees register that could not be amended, modified, altered, to create just a single registry managed centrally, and to have it on an optical memory- again to ensure that would not be altered, but saving time.

My role? Along with a payroll expert and people from the HR and ICT of the customer, do a feasibility study and prepare a proposal for approval by Italian authorities.

So, from the proposal to the submission for approval (as far as I remember it was approved, but I wasn't involved into the follow-up decision and activities, so I do not know if it was implemented), the "stages" in the title of this post were:
  1. a dream: remove the nightmare of having to keep people with the paperwork expertise around the country
  2. an idea: blend a new system with the possibility of removing the paperwork
  3. a project: to integrate people, organization, process, technology into a solution that could be neutral in terms of constraints vs. paper, but with increased efficiency
  4. execution: the "packaging" of all the constraints to obtain first a feasibility confirmation, then carry out the actual project and associated changes
  5. benefits realization: what could be the benefits could be assessed before the project, measured during the project and its execution, monitored during the lifetime of the solution


If you followed my scribblings online since 2008 while I was living in Brussels, or even before when I had my online e-zine 2003-2005 (you can read an updated version released in 2013 of the latter here), you know that quite often I start from current limitations or pitfalls, apply lessons learned from my cross-industry and cross-technology experiences since the 1980s, and inject current and forecasted cultural, business, technological evolutions to see what could happen, and share something ranging from mere transposition to other industries of old ideas, to something that sometimes seems more a nightmare than a dream.

Well, from my first official posts online on change toward an unknown audience in 2003 (as before and up to recently I usually had plenty of sharing offline in my network), most of those "nightmares"/"dreams" eventually turned into reality.

But I am not the only one to write "what ifs" online.

If you read the post in English that I shared above, you will see that one element is missing: execution.

So, in my list above, I would state that that post, as most of the posts within the series "Rethinking Business", are "Level 2".

As many others, I use 5 levels due to something from few decades ago (yes, I am that old), the Software Engineering Institute; you can read the original 1987 article here.

So, what is "level 2"? Formally this was the 1987 list:
  1. Initial: until the process is under statistical control, no orderly progress in process improvement is possible
  2. Repeatable: a stable process with a repeatable level of statistical control is achieved by initiating rigorous project management of commitments, cost, schedule, and change
  3. Defined: definition of the process is necessary to assure consistent implementation and to provide a basis for better understanding of the process. At this point, it is probable that advanced technology can be usefully introduced
  4. Managed: following the defined process, it is possible to initiate process measurements. This is where the most significant quality improvements begin to appear.
  5. Optimized: with a measured process, the foundation is in place forcontinuing improvement and optimization of the process


Incidentally: when assessing change options, have a look at the TurboBPR tool, if you can find a copy- a 1990s tool useful to collect and compare without re-inventing the wheel; it was part of the BPR-CD that I received in the early 1990s as part of "Re-inventing the Government": it was at a time when you just needed to ask, to have lessons learned somewhere else shared (and I too did share my own lessons learned, when asked).

I know that many assume that a whole organization or "ecosystem" has to be at a certain level for a system to be able to operate at that level, but by experience I think that by adopting a "buffering" any organization can strive to stay at a higher level while having bits and pieces within its own organization or supply/value chain that are way behind.

With "buffering" I mean creating areas that shield the best performing areas from the least developed ones, while building in additional resources to actually integrate the latter within a supply/value/knowledge chain with the former: which is a form of overhead and over-kill in resource allocation to cope with differential rates of uncertainty.

Beware: most of the structures in five levels that you see around are actually related to the original 1987 article or its inspirations, but forget to say that they were focused on a specific domain (software engineering) when there was a hope to turn software development into a science with 100% repeatable processes: I too, between the late 1980s and early 1990s, was involved in using and selling Computer Aided Software Engineering tools that promised to enable eventually to generate even the most complex software with just a click on a button after collecting and structuring really high-level, almost human language, requirements.

Now, why this preamble?

Because over the last few weeks my knowledge update on the local market included both the tax/legal update on import/export and electronic invoicing, as well as adding more material on start-ups, digital transformation, and development in Italy, including the broadband initiative that should deliver the infrastructure by 2020/2021.

But when it comes to technology hypes, I am a repeat early adopter (or offender): in the late 1970s I was trying to find a way to increase the speed of knowledge transfer and acquisition, so I first studied the brain, then tried the computer way (in Italy were called "cervello elettronico")- Fortran IV with punched card was really a little bit far away from the brain paraphernalia that I had learned via Eccles Brazier etc.

Ditto for PROLOG and PASCAL in the early 1980s- expert systems were pre-programmed idiots.

Frankly, since 2012 it seems as if legislators in Italy, striving to achieve a level 5 society without abandoning the "ad hoc" and "ad libitum" approach to society (linked to group belonging), and bored with their own circles inability to think bigger, decided that there is a good shortcut.

Blogs, books, articles... assemble the best or most interesting or most convincing or apparently simpler bits- and pronto, you have a new law ready to change society.

Also if other that has a side-effect on some businesses more than others.

Meaning: e.g. by extending to society the same "pre-programmed obsolescence" that information technology has been experiencing at least since the beginning of the PC era (how many times did you swap PC just to be able to use the latest version of a software, just to keep using the same features you used in the previous version).

Nothing is better than compliance to force changing organizational structures, processes, technology: it is an offer that you cannot refuse.

The "common good" is something that still have to learn to practice, more than talk about- but it is a "buffer" that we have to pay to keep moving on.

In Italy we have a saying "il diavolo fa le pentole ma non i coperchi" or equally "il diavolo si nasconde nei dettagli".

If you read books and blogs, you can "lift" plenty of ideas- but unless you have access to the background and experience that resulted in those scribblings, you risk doing something akin to a transplant without checking first if at least the blood type is compatible (e.g. see here; or you can read the book on "market design" by a Nobel Prize winner review here).

Let's discard books and blogs that write about something that they contain neither confirmed knowledge (i.e. direct or from others that are confirmed having the experience) nor experience worth sharing.

Still, all the "connecting-the-dots" exercises, even more than the "best practices sharing", demand that you have a target environment that is compatible with the one you are "lifting" the ideas from.

Otherwise, you can end up as something I heard today confirmed.

As I wrote above, I did update my knowledge on how e-invocing is applied in Italy last summer, but I saw something that both others and I suggested years ago.

Background: I lived in UK and Belgium, worked in few more countries around Europe, and occasionally travelled (for business and personal purposes) elsewhere, while, being curious about cultures and organizations, with my European and non-European friends, colleagues, classmates often ended up sharing knowledge about how our tax and legal systems differ.

Yes, I know, it seems boring- but in my view, learning a language isn't enough, you have to learn also the culture, which includes what is part and parcel of everyday life, including the "social expectations about law and regulations".

Example: as I tirelessly explained to my foreign colleagues since the late 1980s, in Italy we are used to extensions, last minute changes, and even past-midnight reprives and retro-dated laws.

Hence, it is not uncommon that "compliance" with a forthcoming law or regulation in Italy implies a degree of skepticism about implementation, and also fall-back scenarios that in other countries would be considered a waste of resources.

The first case I remember was the preparation for the Y2k (Year 2000- wasn't a bug, just simply that computers were built using concepts derived from when memory and disk space were hugely expensive, and therefore storing just 2 digits instead of 4, plus testing for "greater than was cheaper- pity that 00 is lower than 99): there were plenty of articles about Italy lack of preparation- but, actually, I worked in my first Y2K project in... 1987, for a bank.

Simply: we are used to communicate at the last minute and avoid committing to a "yes" up to the last minute.

I write "we" because I want to share the blame- but I learned in the late 1980s how to overcome that habit- so, I got various not-so-positive nicknames for being excessively "foreign", or "German": until the early 1990s, when I was offered a role in change just for that reason.

Because there is a drawback in being "flexible" with rules: it works in a simple system, while in a larger, more complex system, requires many of those "buffers" I wrote about (the "overhead of flexibility").

In any culture I worked in there is a degree of flexibility: purely "unflexible" system exist only in books written by classical economists: the homo economicus, as it has been nicknamed, is a rational agent that is optimally boringly predictable.

I am more inclined toward the behavioural side (for a funny and relaxing ride through the latter, but still closer to orthodoxy, see the 2008 lectures from another Nobel Prize winner, Robert Shiller, with a 2011 follow-up; on the same domain, worth watching also the one on Game Theory- I wrote about it almost a decade ago, within a series of articles called "GMN2009".

Now, today I had a sad confirmation that the "legislative reform jump-ahead wagon" is confirmed to have already left the train station- while some of the tracks are missing: a common recurrence.

Have you ever seen that amazing video about a machine designed in China to build up bridges fast, basically deploying pre-assembled sections that are then just connected together by the crew, Lego(tm)-like?

Well, it all works based upon the concept that the sections have already been prepared- not that you do not even know the layout...

Lifting ideas from books, blogs, or (more expensive) "learn onsite from the best" business tours is useful- but only if then you have a "filtering phase" that convert that into something contextually workable.

Since 2012 I saw a constant recurring of laws and new "Level 5" systems released by the Italian Government due to legislative and regulatory implementations that decided a jump ahead to avoid being strangled by our Byzanthine and compulsive red-tape.

Trouble is: as shown last July on the first step of e-invoicing, we end up procrastinating implementation so often, that in the end the attempt is to release something anyhow, and fix it later.

Agile is fine with (some) software design, but not with every software, and not with changes that imply then an extended butterfly effect.

The Italian economy is made up by thousands of small towns and hundred of thousands of small companies- neither of which has the internal capabilities to manage a constant stream of change contradicting each other or "fixing" after weeks just a comma here, a comma there.

The cost? This morning at a conference we were told that the EU considers Italy to have 27% of the VAT tax dodging within EU28.

If you look at the nominal GDP in Europe overall (from Eurostat): in 2017, Italy represented 11% of the EU28 GDP; even considering just Euroland (73% of EU28), Italy's GDP is 15% of Euroland (or EU19).

Why the discrepancy? In part, as discussed today, it is because the way statistics are computed.

But in part probably this represents "buffers" between the letter of the hundreds of thousands of rules, regulations, laws applied in Italy, and the reality of their implementation.

What is clear is that GDPR and universal e-invoicing are actually forcing both the State and businesses to move forward and into a cultural paradigm shift.

In Italy we still have way too few people from business temporarily working in State bureaucracy and viceversa- actually, on both sides, shifting to one side even temporarily is a sure career killer, as the two cultures clash more than complement each other.

At a more political level, it happened once in a while, but the two worlds did collide more than once since the aftermath of "Mani Pulite" (early 1990s), when the end of the formal Cold War removed the lid to the Pandora's box that had become Italian politics.

I am fond to repeat often to my friends, colleagues, contacts that in Italy we had many "loans" from society to politics, loans that turned into permanent transfers.

As I repeated today during a coffee, I am puzzled whenever I see a report of a "scandal" because this or that part of the State bureaucracy asks a supplier to help prepare a tender.

Yes, there is a risk of giving preferential access, either directly or through one or few degrees of separation.

But the reality is: in Italy, the 1990s and digitalization/dematerialization (starting i.e. from the 1980s-1990s, with the introduction of distributed computing) weren't matched by a comprehensive cultural shift and building up of the human capital needed to govern the change.

So, we keep embracing technologies that are way beyond our structural cultural capabilities to cope- not just with the surface value, but with the service delivery end-to-end.

Even recently, I heard that one of the various issues that might affect the deployment of the Gigabit society infrastructure (5G and beyond) is... the lack of enough local suppliers able to work on building up that infrastructure.

Many countries have an issue e.g. with the lack of data scientists, but in Italy we lack more common technological skills.

The five steps/levels from dreams to benefits realization show the gap between our never-ending list of overlapping roadmaps, and deployed reality- from smartcities were providers complain that local authorities lack the skills needed to be partners, to the number of authorizations required (in the tens of thousands) to build the broadband, to the unwillingness of small businesses (notably B2C, selling to end consumers) to report.

Therefore, while the above notes about compulsory e-invoicing might seem a critique, are actually an acknowledgement.

In Italy, whenever we had a change, unfortunately in the end changes were pushed through, not negotiated.

Look at how we had the first gas network, decades ago- Mattei speech about the number of authorizations he bypassed with local authorities to lay the pipelines came to mind when I head the discussion of the issues with the current development of the broadband in Italy.

Now, we live in different, supposedly more transparent times- but, probably, changes forcing through the perception of how some "buffers" have to go are the only way to have we Italians see reality as it is.

As a closing note: as a kid, I remember the protests when a road in the centre of Turin, via Garibaldi, was converted into a pedestrian area.

Nowadays, almost nobody would even consider having streetcars, buses, or cars getting through it.

Italy is way behind in terms of digitalization, 25th out of 28th?

Yes, but it is not a matter of money, technology, human capabilities, skills.

It is a matter of cultural ability to think (again, as we did in the past) longer-term, and acknowledge that a project isn't just a blueprint- it is its execution, and that the planning phase should consider at least the lifetime of the benefits that an initiative aims to achieve.

And to differentiate between building something that delivers benefits, and building something that is an enabler.

An enabler is a political choice, not just a matter of ledger balance.

There is a time for both- what matters is remembering that sometimes you build up enablers that represent a different model of society, even when the numbers show no "measurable case" for it based upon known information.

But that requires thinking long-term... and doing something in Italy has disappeared: the willingness to lose an election now and maybe win the next one- so, tinkering is probably going to stay with us with for some time.

PS a note for the locals and those that will have to work with the locals: on @hyperuranos on Instagram I shared some of the key slides from today's workshop on e-invoicing updates. Why I shared? Because, in terms of "Market design", I think that as in any game rules should be shared- and anybody who works in Italy (either directly or with an Italian VAT while being based abroad) or has to deal with Italian companies, might find useful to know the new rules and some potential issues (e.g. when it comes to invoicing, some Italian companies might suddenly become more German than Germans on what is written within an invoice- but there is a reason).

Here are the links (3 parts as Instagram has a 10-pictures-per-post limit).
Part1 https://www.instagram.com/p/Bqu_61dHKDI/?utm_source=ig_share_sheet&igshid=ldc4ms458wzk

Part2
https://www.instagram.com/p/BqvAD7nHIwl/?utm_source=ig_share_sheet&igshid=c8nckld7ovgt

Part3
https://www.instagram.com/p/BqvAMKYHY8n/?utm_source=ig_share_sheet&igshid=13utvs83pp4lj

PPS and yes, the benefits realization part is a side-effect from MSP (Managing Successful Programmes) UK methodology- I remember an interesting case study about a case that was