Why Excel Is Breaking Your Business Processes (Shadow System Problem)

1
00:00:00,000 --> 00:00:04,400
My name is Mirko Peters and I translate how technology actually shapes business reality.

2
00:00:04,400 --> 00:00:08,000
Most leaders believe their biggest hurdles are found in strategy, budgets, or the people

3
00:00:08,000 --> 00:00:09,000
they hire.

4
00:00:09,000 --> 00:00:11,800
But if you look closely, the real drag sits somewhere else entirely.

5
00:00:11,800 --> 00:00:16,300
It lives inside a hidden process architecture that has slowly disappeared into messy Excel

6
00:00:16,300 --> 00:00:19,400
files, endless email chains, and private work habits.

7
00:00:19,400 --> 00:00:23,400
I want to use a company called Contoso Manufacturing as our throughline today, not because they

8
00:00:23,400 --> 00:00:27,200
are unusual but because their situation feels so incredibly normal.

9
00:00:27,200 --> 00:00:31,900
We are going to expose their shadow systems, map the specific patterns where they fail,

10
00:00:31,900 --> 00:00:34,900
and look at the governed path that actually leads out of the woods.

11
00:00:34,900 --> 00:00:38,500
If this is the kind of conversation you want to hear more of, hit subscribe, and let's

12
00:00:38,500 --> 00:00:42,000
start with what Contoso thinks is happening inside their walls.

13
00:00:42,000 --> 00:00:44,100
Contoso looks normal from the outside.

14
00:00:44,100 --> 00:00:47,600
From the outside, Contoso looks perfectly fine and that is exactly why this matters so

15
00:00:47,600 --> 00:00:49,300
much for any growing business.

16
00:00:49,300 --> 00:00:53,760
They are a mid-sized company with capable managers, decent margins, and a technology stack that

17
00:00:53,760 --> 00:00:56,480
sounds respectable enough to put on a board slide.

18
00:00:56,480 --> 00:01:00,920
Microsoft 365 is fully deployed, their teams channels stay busy, and Outlook is constantly

19
00:01:00,920 --> 00:01:02,640
overloaded with communication.

20
00:01:02,640 --> 00:01:06,520
There are shared drives and sharepoint sites everywhere, filled with spreadsheets with

21
00:01:06,520 --> 00:01:12,760
names like Final V7 approved use this one, while a leadership team feels with some justification

22
00:01:12,760 --> 00:01:15,400
that the business is moving in the right direction.

23
00:01:15,400 --> 00:01:19,400
If you walked through the building or joined a few of their meetings, you would probably

24
00:01:19,400 --> 00:01:21,160
agree that things are on track.

25
00:01:21,160 --> 00:01:25,280
People are not sitting around confused or idle because they are clearly working and their

26
00:01:25,280 --> 00:01:27,880
calendars stay packed from morning until night.

27
00:01:27,880 --> 00:01:32,840
Procurement is processing requests, finance is reviewing the latest numbers, and operations

28
00:01:32,840 --> 00:01:37,200
is busy tracking exceptions while HR chases down the next round of approvals.

29
00:01:37,200 --> 00:01:41,240
Sales is sending out forecasts and everyone can point to specific output, and because that

30
00:01:41,240 --> 00:01:45,440
output exists, the operating model feels much more stable than it actually is.

31
00:01:45,440 --> 00:01:49,080
But stability at the surface can easily hide fragility underneath because a company can

32
00:01:49,080 --> 00:01:53,360
look coordinated while the coordination itself is happening through invisible manual effort

33
00:01:53,360 --> 00:01:55,360
that nobody owns end to end.

34
00:01:55,360 --> 00:01:56,840
So let's stay with Contoso for a minute.

35
00:01:56,840 --> 00:02:01,280
A vacation request might start in one file, and then move through email because a manager

36
00:02:01,280 --> 00:02:04,040
wants extra context before hitting approve.

37
00:02:04,040 --> 00:02:08,160
Procurement requests often begin with a spreadsheet attachment because the form in the old portal

38
00:02:08,160 --> 00:02:12,640
never got updated, and exception handling for supplier issues sits in someone's personal

39
00:02:12,640 --> 00:02:17,360
inbox because the official system cannot capture the extra notes people need.

40
00:02:17,360 --> 00:02:20,840
Simply reporting gets assembled from multiple local files because every team keeps the

41
00:02:20,840 --> 00:02:25,080
version that works best for them, yet none of this feels dramatic on its own.

42
00:02:25,080 --> 00:02:29,360
Each work around solves a real blockage in the moment, and that is exactly why these

43
00:02:29,360 --> 00:02:31,120
patterns survive and thrive.

44
00:02:31,120 --> 00:02:34,600
People do not wake up and decide to build a shadow system, but they will always remove

45
00:02:34,600 --> 00:02:37,440
friction wherever they find it to get the work through the door.

46
00:02:37,440 --> 00:02:41,360
If one team needs a data field that does not exist in the formal system, they simply add

47
00:02:41,360 --> 00:02:42,840
a new column in Excel.

48
00:02:42,840 --> 00:02:47,400
If an approval path changes too often to wait for an IT update, they root it through mail

49
00:02:47,400 --> 00:02:48,480
and memory instead.

50
00:02:48,480 --> 00:02:53,080
When leadership asks for a number by four o'clock, nobody pauses to redesign the architecture

51
00:02:53,080 --> 00:02:56,840
so they copy, paste, reconcile, and send the deck.

52
00:02:56,840 --> 00:03:00,520
From a human perspective, this looks like responsible employees taking initiative.

53
00:03:00,520 --> 00:03:04,240
From an architectural perspective, it creates an operating layer that is real and business

54
00:03:04,240 --> 00:03:06,720
critical, yet almost completely ungoverned.

55
00:03:06,720 --> 00:03:07,720
And why is that?

56
00:03:07,720 --> 00:03:12,000
It happens because leadership usually sees individual tasks rather than the actual flow

57
00:03:12,000 --> 00:03:12,760
of work.

58
00:03:12,760 --> 00:03:16,680
You see that requests were approved, reports were produced, and customers were served, but

59
00:03:16,680 --> 00:03:20,600
they do not see how much hidden-rooting logic sits between those outcomes.

60
00:03:20,600 --> 00:03:24,120
They miss who forwarded the attachment, who renamed the file, and who remembered the

61
00:03:24,120 --> 00:03:26,200
specific threshold for a certain client.

62
00:03:26,200 --> 00:03:29,920
They don't see who chased the approver or who knew that if a specific plant manager was

63
00:03:29,920 --> 00:03:34,760
traveling, the request had to go to finance first, then procurement, and then back again.

64
00:03:34,760 --> 00:03:39,400
That logic exists, and it runs every single day, but it is stored in habits, inboxes,

65
00:03:39,400 --> 00:03:41,920
file parts, and the minds of a few trusted people.

66
00:03:41,920 --> 00:03:46,040
That means Contoso is not really running on process in the formal sense, but is instead

67
00:03:46,040 --> 00:03:47,600
running on hidden coordination.

68
00:03:47,600 --> 00:03:51,200
This is where a lot of leaders misread the situation because they look at a busy company

69
00:03:51,200 --> 00:03:53,960
and assume that busyness proves operating maturity.

70
00:03:53,960 --> 00:03:58,280
But busyness can also be a form of structural compensation, where the people inside the company

71
00:03:58,280 --> 00:04:01,440
are constantly filling gaps the architecture leaves open.

72
00:04:01,440 --> 00:04:04,960
They are translating between systems that do not connect, preserving context that the

73
00:04:04,960 --> 00:04:08,960
process does not carry, and rebuilding clarity every time work crosses a boundary.

74
00:04:08,960 --> 00:04:13,000
The business still moves and that is the trap, because when a company survives through invisible

75
00:04:13,000 --> 00:04:16,800
coordination, the output masks the design weakness.

76
00:04:16,800 --> 00:04:21,000
Leadership sees activity, the teams feel the pressure, the spreadsheets grow, and the inboxes

77
00:04:21,000 --> 00:04:22,000
fill.

78
00:04:22,000 --> 00:04:25,280
The company tells itself the same story many organizations tell, which is that they are a

79
00:04:25,280 --> 00:04:27,400
bit overloaded, but basically functional.

80
00:04:27,400 --> 00:04:29,280
Actually, wait, let me clarify that.

81
00:04:29,280 --> 00:04:33,000
Contoso is functional, but it is functional in the way a building can still stand while

82
00:04:33,000 --> 00:04:35,960
more and more of its weight sits on temporary supports.

83
00:04:35,960 --> 00:04:40,240
If those supports are undocumented files, personal memory and manual handoffs, then what looks

84
00:04:40,240 --> 00:04:42,920
efficient today can fail very quickly tomorrow.

85
00:04:42,920 --> 00:04:46,520
So this is not a story about a messy company and it is not about poor discipline or lazy

86
00:04:46,520 --> 00:04:47,520
process owners.

87
00:04:47,520 --> 00:04:51,320
It is a company with competent people solving real work through an operating model that hides

88
00:04:51,320 --> 00:04:52,520
its own dependencies.

89
00:04:52,520 --> 00:04:56,880
Once we stop looking at isolated tasks and start looking at how work actually flows, the

90
00:04:56,880 --> 00:04:59,160
picture changes completely.

91
00:04:59,160 --> 00:05:00,160
The first signal?

92
00:05:00,160 --> 00:05:01,760
Approval cycle time drift.

93
00:05:01,760 --> 00:05:05,280
Now we need to move from how things feel at Contoso to what the process is actually doing

94
00:05:05,280 --> 00:05:06,360
to the business.

95
00:05:06,360 --> 00:05:10,080
The first signal you'll notice is something I call approval cycle time drift.

96
00:05:10,080 --> 00:05:14,480
On paper, a procurement approval at a company like this should take somewhere between 24

97
00:05:14,480 --> 00:05:15,720
and 48 hours.

98
00:05:15,720 --> 00:05:19,640
That sounds reasonable because a request comes in, the manager checks it, finance reviews

99
00:05:19,640 --> 00:05:24,040
the threshold and procurement confirms the vendor before the order finally gets placed.

100
00:05:24,040 --> 00:05:27,840
If you asked anyone close to the operation, they would describe it exactly like that.

101
00:05:27,840 --> 00:05:31,360
As a short sequence with a few standard checks and a normal delay here and there, but when

102
00:05:31,360 --> 00:05:35,340
you measure the actual elapsed time, instead of the intended time, a completely different

103
00:05:35,340 --> 00:05:36,840
picture starts to appear.

104
00:05:36,840 --> 00:05:41,280
That same approval that should close in a day or two is often taking 5, 7 or even 12 days

105
00:05:41,280 --> 00:05:42,400
to complete.

106
00:05:42,400 --> 00:05:46,880
This doesn't happen because one person refused to act or because the whole business stopped

107
00:05:46,880 --> 00:05:51,720
moving and it's rarely because the request itself was unusually complex.

108
00:05:51,720 --> 00:05:56,040
The time simply disappears in the dark spaces between the steps where the work looks active

109
00:05:56,040 --> 00:05:59,000
from a distance but sits completely idle in practice.

110
00:05:59,000 --> 00:06:03,640
A typical request usually arrives as an email with a spreadsheet attached to it.

111
00:06:03,640 --> 00:06:07,800
The manager opens the file, notices one field is a bit unclear and immediately forwards

112
00:06:07,800 --> 00:06:10,040
it back to the requester for clarification.

113
00:06:10,040 --> 00:06:13,880
Once the requester updates the file and changes the name, they send it back again and the

114
00:06:13,880 --> 00:06:17,760
manager approves it but adds finance to the chain because the amount feels like it might

115
00:06:17,760 --> 00:06:19,240
hit a limit.

116
00:06:19,240 --> 00:06:23,240
Finance is stuck in meetings all afternoon so they see the mail later and ask if this version

117
00:06:23,240 --> 00:06:27,080
is the latest one because another copy already arrived through a different chain.

118
00:06:27,080 --> 00:06:30,480
The procurement waits because they don't want to act on the wrong attachment then someone

119
00:06:30,480 --> 00:06:35,160
goes on leave and the whole thing stalls because nobody is fully sure who owns the next step.

120
00:06:35,160 --> 00:06:37,920
I want you to notice what actually happened in that sequence.

121
00:06:37,920 --> 00:06:42,880
The delay didn't come from one bad approver but instead it grew out of handoffs, inbox

122
00:06:42,880 --> 00:06:46,880
waiting, attachment forwarding and the total absence of a single visible path.

123
00:06:46,880 --> 00:06:51,320
This is where many leaders misread cycle time because they hear that approvals are slow

124
00:06:51,320 --> 00:06:53,480
and assume the answer is to apply more pressure.

125
00:06:53,480 --> 00:06:58,200
They try to push managers harder, escalate response times or send automated reminders but

126
00:06:58,200 --> 00:07:00,760
reminders cannot fix invisible routing logic.

127
00:07:00,760 --> 00:07:03,560
The problem isn't the speed of effort, it's the speed of the architecture.

128
00:07:03,560 --> 00:07:07,160
When a process cannot hold its own state, the people inside it have to reconstruct that

129
00:07:07,160 --> 00:07:09,920
state manually every single time they touch a task.

130
00:07:09,920 --> 00:07:14,120
They have to ask if this is the latest file, if finance has seen it or if the threshold

131
00:07:14,120 --> 00:07:15,120
was already checked.

132
00:07:15,120 --> 00:07:19,160
Since nobody wants to guess and risk a mistake, everybody hesitates just a little bit.

133
00:07:19,160 --> 00:07:23,320
That hesitation compounds across the entire chain and what looked like a one day process

134
00:07:23,320 --> 00:07:27,320
becomes a seven day or deal without any single dramatic failure occurring.

135
00:07:27,320 --> 00:07:31,520
From an executive perspective, this shift matters a lot because time drift is actually architecture

136
00:07:31,520 --> 00:07:32,520
drift.

137
00:07:32,520 --> 00:07:36,320
The business believes it operates with one clear approval model but in reality it operates

138
00:07:36,320 --> 00:07:40,480
with a loose collection of local interpretations stitched together by email behavior.

139
00:07:40,480 --> 00:07:44,320
The formal process still exists as a diagram in a drawer but the runtime process, the one

140
00:07:44,320 --> 00:07:48,760
that consumes days and money, lives somewhere else entirely and this is why elapsed time is such

141
00:07:48,760 --> 00:07:50,880
a powerful signal for us to track.

142
00:07:50,880 --> 00:07:55,400
Time exposes hidden design flaws that people can usually hide behind extra effort for a short

143
00:07:55,400 --> 00:07:56,400
while.

144
00:07:56,400 --> 00:08:00,520
They can work late, they can chase answers and they can manually root work around a blocked

145
00:08:00,520 --> 00:08:03,400
step but they cannot hide what the clock records.

146
00:08:03,400 --> 00:08:07,800
If a two day process regularly takes nine days to finish, your process architecture isn't

147
00:08:07,800 --> 00:08:10,840
just slightly inefficient, it is fundamentally unstable.

148
00:08:10,840 --> 00:08:15,080
There is another layer to this where the process appears busy while no real work is actually

149
00:08:15,080 --> 00:08:16,080
progressing.

150
00:08:16,080 --> 00:08:20,680
Emails are moving, attachments are circulating and people are being copied on status discussions

151
00:08:20,680 --> 00:08:24,040
but the request itself is just parked in a state of uncertainty.

152
00:08:24,040 --> 00:08:28,000
The organization experiences a lot of motion without any real throughput which is one of the

153
00:08:28,000 --> 00:08:30,600
most expensive illusions a company can run on.

154
00:08:30,600 --> 00:08:34,440
Once time starts disappearing into handoffs like this the cost doesn't stay hidden for long

155
00:08:34,440 --> 00:08:36,920
it just shows up somewhere else in the system.

156
00:08:36,920 --> 00:08:41,160
The second signal rework as a system outcome, at Contoso that next place where the cost

157
00:08:41,160 --> 00:08:45,680
appears is in rework, this is our second signal and in many ways it tells us more than

158
00:08:45,680 --> 00:08:50,920
cycle time ever could, while a delay can still look like a simple scheduling problem, rework

159
00:08:50,920 --> 00:08:55,200
shows that the company is spending expensive effort to recreate work it already finished

160
00:08:55,200 --> 00:08:56,200
once.

161
00:08:56,200 --> 00:08:59,240
Think about what happens after a request finally manages to move forward.

162
00:08:59,240 --> 00:09:03,120
The data from the spreadsheet gets copied into another file for the finance review and

163
00:09:03,120 --> 00:09:07,080
then procurement enters parts of that same information into a purchasing system because

164
00:09:07,080 --> 00:09:09,480
they don't trust the attachment as a source of record.

165
00:09:09,480 --> 00:09:13,480
A manager might edit one version locally while someone else updates an older copy from

166
00:09:13,480 --> 00:09:14,800
a different email thread.

167
00:09:14,800 --> 00:09:19,160
Eventually the numbers don't match so somebody has to stop everything to compare cells, check

168
00:09:19,160 --> 00:09:22,280
timestamps and rebuild the request history by hand.

169
00:09:22,280 --> 00:09:26,400
Nothing in that entire sequence creates any new value for the company it is just a system

170
00:09:26,400 --> 00:09:30,040
repairing its own losses and that is why I want to frame this carefully.

171
00:09:30,040 --> 00:09:32,600
Rework is often described as simple sloppiness.

172
00:09:32,600 --> 00:09:36,600
We blame someone for keying the wrong amount using an old file or for getting the latest

173
00:09:36,600 --> 00:09:40,880
comments but if the same kinds of mistakes happen again and again across different functions

174
00:09:40,880 --> 00:09:45,280
it stops being a personal issue and becomes a design issue it's a system outcome.

175
00:09:45,280 --> 00:09:49,440
At Contoso this pattern shows up in version conflicts, manual data reentry and constant

176
00:09:49,440 --> 00:09:51,680
copying and pasting between different tools.

177
00:09:51,680 --> 00:09:55,480
You see it in parallel edits happening in separate files and late stage corrections when

178
00:09:55,480 --> 00:09:59,040
finance realizes the attachment doesn't match the email.

179
00:09:59,040 --> 00:10:02,960
Manager reviews get repeated constantly because the original context was stripped out somewhere

180
00:10:02,960 --> 00:10:03,960
during the transit.

181
00:10:03,960 --> 00:10:08,240
If you measured it honestly you would probably find that 15 to 30% of the work is being

182
00:10:08,240 --> 00:10:12,040
re-done in some form. This doesn't happen because people are careless but because the process

183
00:10:12,040 --> 00:10:15,880
does not preserve state cleanly as work moves from one step to the next.

184
00:10:15,880 --> 00:10:18,520
That distinction is vital for a leader to understand.

185
00:10:18,520 --> 00:10:23,440
A good process carries context forward automatically but a weak process sheds context at every

186
00:10:23,440 --> 00:10:27,320
handoff and then asks the people inside it to reconstruct what was already known.

187
00:10:27,320 --> 00:10:32,400
So when leaders ask why a team keeps touching the same request three times the better translation

188
00:10:32,400 --> 00:10:36,040
is that the team isn't slow the system is just making them repeat themselves.

189
00:10:36,040 --> 00:10:39,760
As you see that a lot of management frustration starts to make much more sense.

190
00:10:39,760 --> 00:10:43,440
Finance keeps asking for the same clarification because that information stayed in someone's

191
00:10:43,440 --> 00:10:46,400
private inbox instead of staying with the process.

192
00:10:46,400 --> 00:10:50,760
Procurement keeps checking thresholds manually because that logic lives in old policy documents

193
00:10:50,760 --> 00:10:54,000
and human memory rather than in the digital runtime.

194
00:10:54,000 --> 00:10:58,040
Managers feel buried in small approvals because every incomplete handoff sends ambiguous work

195
00:10:58,040 --> 00:10:59,920
back upstream for them to fix.

196
00:10:59,920 --> 00:11:03,800
The people inside the system are not just doing the work, they are constantly compensating

197
00:11:03,800 --> 00:11:05,440
for a missing structure.

198
00:11:05,440 --> 00:11:09,960
This is one of the most expensive forms of waste because it spreads quietly and rarely appears

199
00:11:09,960 --> 00:11:12,240
as a clean line item on a budget.

200
00:11:12,240 --> 00:11:16,920
Nobody writes reconstructed context into a monthly operating report and nobody creates a dashboard

201
00:11:16,920 --> 00:11:19,480
for hours lost comparing attachments.

202
00:11:19,480 --> 00:11:23,680
But the cost is very real and it lands in labor, delay, error correction and management

203
00:11:23,680 --> 00:11:24,760
attention all at once.

204
00:11:24,760 --> 00:11:29,160
I've seen this pattern in enough organizations to know that rework often gets misdiagnosed

205
00:11:29,160 --> 00:11:30,480
as a training problem.

206
00:11:30,480 --> 00:11:34,000
We tell ourselves to train people harder at another checklist or remind teams to use the

207
00:11:34,000 --> 00:11:38,880
right file names, but if the architecture still depends on file copies and manual transfers,

208
00:11:38,880 --> 00:11:41,920
then training just becomes another form of structural compensation.

209
00:11:41,920 --> 00:11:46,200
You are trying to force discipline onto a fragile path instead of just fixing the path

210
00:11:46,200 --> 00:11:47,200
itself.

211
00:11:47,200 --> 00:11:50,720
From a system perspective that's not just inefficient, it's fragile.

212
00:11:50,720 --> 00:11:54,920
Every repeated touch point creates another chance for a mismatch, another chance for a delay,

213
00:11:54,920 --> 00:11:58,520
and another chance for the business to lose confidence in what it thinks it knows.

214
00:11:58,520 --> 00:12:03,360
This is where rework starts changing from an operations problem into a trust problem.

215
00:12:03,360 --> 00:12:07,200
When the same request gets handled twice or interpreted differently in two different files,

216
00:12:07,200 --> 00:12:08,560
people stop trusting the numbers.

217
00:12:08,560 --> 00:12:12,520
That shift matters more than most leaders realize because once work gets done twice often

218
00:12:12,520 --> 00:12:15,480
enough, the next thing that breaks isn't speed.

219
00:12:15,480 --> 00:12:18,640
It's the confidence in the operating picture itself.

220
00:12:18,640 --> 00:12:21,640
The third signal, data inconsistency, becomes trust failure.

221
00:12:21,640 --> 00:12:25,040
Once confidence in the work itself starts to weaken, the next thing you need to watch is

222
00:12:25,040 --> 00:12:26,040
the data.

223
00:12:26,040 --> 00:12:29,480
This is the third signal and at a company like Contours or the same business unit can

224
00:12:29,480 --> 00:12:33,040
produce three different answers to the exact same question without anyone trying to

225
00:12:33,040 --> 00:12:34,600
manipulate the results.

226
00:12:34,600 --> 00:12:38,000
That is what makes this problem so difficult to spot at first because the issue isn't bad

227
00:12:38,000 --> 00:12:42,880
intent, it's actually a combination of bad timing, source confusion and process fragmentation.

228
00:12:42,880 --> 00:12:46,720
Imagine the leadership team asks a simple question about the current procurement backlog

229
00:12:46,720 --> 00:12:49,760
and how much of it sits outside the policy threshold.

230
00:12:49,760 --> 00:12:53,240
Operations pulls a number from the spreadsheet used by their coordinators.

231
00:12:53,240 --> 00:12:57,520
While finance brings a different figure from the monthly reconciliation file, and procurement

232
00:12:57,520 --> 00:13:01,480
has a third number because their team filtered the late requests based on the version they

233
00:13:01,480 --> 00:13:02,960
trust most.

234
00:13:02,960 --> 00:13:06,600
All three groups are acting in good faith and can explain their logic, yet all three groups

235
00:13:06,600 --> 00:13:08,880
can still be wrong in relation to each other.

236
00:13:08,880 --> 00:13:12,320
That is the exact moment when a management meeting stops being about making decisions and

237
00:13:12,320 --> 00:13:14,240
turns into a reconciliation meeting.

238
00:13:14,240 --> 00:13:18,560
The conversation shifts to which Excel file is correct, who updated a specific tab, and

239
00:13:18,560 --> 00:13:23,040
why finance shows 27 open requests while procurement shows 34.

240
00:13:23,040 --> 00:13:26,560
People start asking if the exceptions were already counted or if those are still sitting

241
00:13:26,560 --> 00:13:30,800
in Sarah's tracker, and they wonder if the data was extracted before or after the manager

242
00:13:30,800 --> 00:13:33,520
approvals came in yesterday afternoon.

243
00:13:33,520 --> 00:13:37,480
Once those questions become the norm, the company is no longer dealing with simple reporting

244
00:13:37,480 --> 00:13:41,080
friction, it is dealing with a total trust failure in its operating picture.

245
00:13:41,080 --> 00:13:44,720
This is a serious shift because businesses do not run on data alone, they run on shared

246
00:13:44,720 --> 00:13:48,560
confidence in what that data means right now and whether everyone in the room is looking

247
00:13:48,560 --> 00:13:50,040
at the same reality.

248
00:13:50,040 --> 00:13:54,520
If that confidence drops, decisions slow down, even when the report still arrive on time,

249
00:13:54,520 --> 00:13:59,520
and the result is a system where people hedge more and constantly ask for another validation.

250
00:13:59,520 --> 00:14:04,120
They defer action until someone can check the numbers, and eventually they stop trusting

251
00:14:04,120 --> 00:14:07,080
the process and start trusting familiar individuals instead.

252
00:14:07,080 --> 00:14:11,480
In a healthy architecture, the report settles the question, but in a shadow system, the

253
00:14:11,480 --> 00:14:13,400
report is just the start of the argument.

254
00:14:13,400 --> 00:14:17,440
Now map that to what work actually feels like inside Contoso, where finance spends extra

255
00:14:17,440 --> 00:14:21,160
time validating line items before closing a monthly view.

256
00:14:21,160 --> 00:14:25,040
And operations keeps a local file because they don't trust the shared one to reflect

257
00:14:25,040 --> 00:14:27,080
late exceptions.

258
00:14:27,080 --> 00:14:30,960
Others ask analysts for the real number, which usually just means the version adjusted by

259
00:14:30,960 --> 00:14:32,520
someone with the right context.

260
00:14:32,520 --> 00:14:36,920
So even when dashboards exist, they sit on top of unstable inputs.

261
00:14:36,920 --> 00:14:40,960
The presentation looks digital, but the coordination underneath is still manual, and this is where

262
00:14:40,960 --> 00:14:43,640
leaders often underestimate the true cost.

263
00:14:43,640 --> 00:14:47,520
They look at inconsistent numbers and think the answer is abstract data governance or cleaner

264
00:14:47,520 --> 00:14:51,720
definitions, but if the process generating that data still depends on email attachments

265
00:14:51,720 --> 00:14:55,920
and local copies, then inconsistency is a runtime problem.

266
00:14:55,920 --> 00:15:00,000
The process cannot produce one trusted record because it was never built to preserve one,

267
00:15:00,000 --> 00:15:03,680
and the consequence goes far beyond executive frustration.

268
00:15:03,680 --> 00:15:08,160
Audit exposure starts rising, compliance, conversations get harder, and the exception

269
00:15:08,160 --> 00:15:10,480
history becomes almost impossible to reconstruct.

270
00:15:10,480 --> 00:15:14,240
Nobody can show cleanly and quickly who changed what or when it happened.

271
00:15:14,240 --> 00:15:17,960
So when an auditor asks for the trail behind a threshold exception, the company doesn't

272
00:15:17,960 --> 00:15:22,080
retrieve the answer from architecture, it assembles the answer from fragments.

273
00:15:22,080 --> 00:15:25,120
That is expensive, and it is also incredibly risky.

274
00:15:25,120 --> 00:15:29,640
When evidence depends on memory, inbox searches, and file archaeology control is mostly performative,

275
00:15:29,640 --> 00:15:33,680
and the company may feel governed because responsible people are involved, but the underlying

276
00:15:33,680 --> 00:15:35,840
process isn't carrying the load.

277
00:15:35,840 --> 00:15:39,760
The people are, this creates another structural shift where trust in the data drops, and

278
00:15:39,760 --> 00:15:44,720
people rely on the analyst who always knows the right number, or the coordinator who understands

279
00:15:44,720 --> 00:15:46,200
the file.

280
00:15:46,200 --> 00:15:50,080
On the surface that looks like expertise, but from a system perspective, it is something

281
00:15:50,080 --> 00:15:51,080
else entirely.

282
00:15:51,080 --> 00:15:52,480
It is concentration.

283
00:15:52,480 --> 00:15:57,200
And concentration is risk, because the business is no longer running on an observable process.

284
00:15:57,200 --> 00:16:01,680
It is running on memory, interpretation, and a few human bridges holding the entire picture

285
00:16:01,680 --> 00:16:02,680
together.

286
00:16:02,680 --> 00:16:05,440
The hidden metric nobody tracks key person dependency.

287
00:16:05,440 --> 00:16:09,240
This brings us to a metric that almost nobody tracks in a serious way, even though it tells

288
00:16:09,240 --> 00:16:13,640
you more about operational resilience than half the dashboards most companies review every

289
00:16:13,640 --> 00:16:14,640
month.

290
00:16:14,640 --> 00:16:18,800
Key person dependency does not show up as a formal KPI at Contoso, and nobody puts it on

291
00:16:18,800 --> 00:16:22,600
the board pack or labels it as a risk until something finally breaks.

292
00:16:22,600 --> 00:16:26,240
But everyone inside the company knows it exists because they use the same sentence every

293
00:16:26,240 --> 00:16:28,720
shadow system eventually produces.

294
00:16:28,720 --> 00:16:30,720
Only Sarah understands this spreadsheet.

295
00:16:30,720 --> 00:16:34,600
You can swap Sarah for any other name, but the pattern stays the same where one person knows

296
00:16:34,600 --> 00:16:37,880
which tab matters and remembers the logic behind the colors.

297
00:16:37,880 --> 00:16:42,520
One person understands why the number in column H doesn't match the report unless you exclude

298
00:16:42,520 --> 00:16:46,360
a certain supplier group, and they know which approval path changed last quarter even

299
00:16:46,360 --> 00:16:48,760
if that change was never fully documented.

300
00:16:48,760 --> 00:16:53,120
The file looks shared, but the understanding is concentrated, and from a system perspective

301
00:16:53,120 --> 00:16:54,720
that is a single point of failure.

302
00:16:54,720 --> 00:16:58,560
The reason companies tolerate this for so long is simple, in the short term concentration

303
00:16:58,560 --> 00:16:59,560
looks efficient.

304
00:16:59,560 --> 00:17:03,880
If Sarah can resolve questions quickly and fix the broken formulas, the business experiences

305
00:17:03,880 --> 00:17:06,680
her as highly capable, which she probably is.

306
00:17:06,680 --> 00:17:10,080
But capability and resilience are not the same thing, and the company can be grateful for

307
00:17:10,080 --> 00:17:14,080
expertise while still being structurally fragile because that expertise sits in only one

308
00:17:14,080 --> 00:17:15,080
place.

309
00:17:15,080 --> 00:17:19,200
Map that to business reality and imagine Sarah takes leave for two weeks, gets promoted

310
00:17:19,200 --> 00:17:20,600
or moves to another team.

311
00:17:20,600 --> 00:17:25,640
Suddenly a workflow that felt inconvenient but manageable becomes unstable very fast, and

312
00:17:25,640 --> 00:17:30,040
requests wait longer because nobody knows which file drives the current month.

313
00:17:30,040 --> 00:17:34,280
Finance hesitates because the formulas do not reconcile, and managers send more messages

314
00:17:34,280 --> 00:17:38,520
because the status is unclear, leading the organization to discover that what looked like

315
00:17:38,520 --> 00:17:43,560
process discipline was really just human memory standing in for architecture.

316
00:17:43,560 --> 00:17:48,320
I believe leaders need to stop treating concentrated knowledge as a sign of maturity because concentration

317
00:17:48,320 --> 00:17:52,800
is not expertise, it is fragility when the process depends on it to function.

318
00:17:52,800 --> 00:17:56,640
This doesn't reduce the value of skilled people, but it changes what we ask the architecture

319
00:17:56,640 --> 00:17:57,640
to carry.

320
00:17:57,640 --> 00:18:02,040
And in a resilient company, people add judgment and context rather than acting as the only

321
00:18:02,040 --> 00:18:03,960
place where process knowledge lives.

322
00:18:03,960 --> 00:18:07,480
If the spreadsheet, the inbox and the person all have to stay in sync for the business

323
00:18:07,480 --> 00:18:11,840
to move, then the company has not built redundancy, it has built dependents.

324
00:18:11,840 --> 00:18:15,400
Depends without redundancy do not scale well, and they break under pressure because every

325
00:18:15,400 --> 00:18:19,000
increase in volume or urgency puts more load on the same human bridge.

326
00:18:19,000 --> 00:18:23,000
At Contoso you can already see the symptoms as people wait for certain individuals before

327
00:18:23,000 --> 00:18:27,000
closing decisions or meetings get delayed because we need her number first.

328
00:18:27,000 --> 00:18:31,360
Approval slowdown when one manager is traveling because nobody is sure which exception path applies,

329
00:18:31,360 --> 00:18:35,680
and local workarounds multiply around trusted people, which only makes them more central

330
00:18:35,680 --> 00:18:36,680
to the problem.

331
00:18:36,680 --> 00:18:40,680
The irony is that the company often celebrates the people who hold the shadow system together

332
00:18:40,680 --> 00:18:44,760
while ignoring the fact that needing heroes at all is a design warning.

333
00:18:44,760 --> 00:18:47,880
From an executive view, the implication is direct.

334
00:18:47,880 --> 00:18:51,040
Resilience is low even when the output still looks acceptable.

335
00:18:51,040 --> 00:18:54,760
The business may be shipping and reporting, but it is doing it through concentration risk

336
00:18:54,760 --> 00:18:59,200
that stays invisible until absence exposes it, and once that becomes normal, the company

337
00:18:59,200 --> 00:19:00,840
is no longer running on process.

338
00:19:00,840 --> 00:19:05,320
It is running on memory, it's memory in files, memory in naming habits, and memory in

339
00:19:05,320 --> 00:19:08,960
people who carry undocumented assumptions from one week to the next.

340
00:19:08,960 --> 00:19:12,580
Which brings me to the next question, because if this pattern is so fragile, why do smart

341
00:19:12,580 --> 00:19:14,640
teams keep rebuilding it anyway?

342
00:19:14,640 --> 00:19:17,520
Why smart people keep rebuilding the same workaround?

343
00:19:17,520 --> 00:19:21,920
So why does this keep happening, even when the pain is obvious to almost everyone involved?

344
00:19:21,920 --> 00:19:24,680
The answer is simple, the workaround works, at least in the moment.

345
00:19:24,680 --> 00:19:28,680
That is the part leaders often underestimate when they look at process architecture.

346
00:19:28,680 --> 00:19:33,160
Excel survives inside large companies not because people are irrational, but because a spreadsheet

347
00:19:33,160 --> 00:19:36,840
is fast, available, familiar, and politically easy to deploy.

348
00:19:36,840 --> 00:19:38,920
It is already there on every desktop.

349
00:19:38,920 --> 00:19:42,560
Nobody needs a three month procurement cycle just to open a blank workbook, and nobody

350
00:19:42,560 --> 00:19:47,200
needs a steering committee to add a tab, change a column, or forward a file to three people

351
00:19:47,200 --> 00:19:50,200
with a note saying to use this version going forward.

352
00:19:50,200 --> 00:19:54,960
The barrier to action is almost zero, which means the business can respond to friction immediately,

353
00:19:54,960 --> 00:19:56,920
rather than waiting for a formal roadmap.

354
00:19:56,920 --> 00:20:01,800
And when people are under pressure, immediate relief usually beats structural repair.

355
00:20:01,800 --> 00:20:04,040
That is not a character flow in your employees.

356
00:20:04,040 --> 00:20:05,680
And is a predictable system response?

357
00:20:05,680 --> 00:20:10,000
If a team needs a data field that the existing enterprise tool does not support, they will

358
00:20:10,000 --> 00:20:14,360
not wait three months for a backlog slot just to protect architectural purity.

359
00:20:14,360 --> 00:20:16,200
They will add the field somewhere else.

360
00:20:16,200 --> 00:20:19,680
If a manager needs visibility into an approval status this afternoon, someone will build

361
00:20:19,680 --> 00:20:21,440
a manual tracker to get the answer.

362
00:20:21,440 --> 00:20:25,160
If finance needs a threshold check before the month enclosed, somebody will create a

363
00:20:25,160 --> 00:20:27,800
formula and share the file across the department.

364
00:20:27,800 --> 00:20:32,440
The business reaches for the thing that removes friction now, not the thing that creates

365
00:20:32,440 --> 00:20:35,000
a clean operating structure six months from now.

366
00:20:35,000 --> 00:20:38,560
That is why shadow systems spread through competent organizations so easily.

367
00:20:38,560 --> 00:20:42,800
The people inside them are solving real constraints with the tools they can access fastest.

368
00:20:42,800 --> 00:20:43,800
And why is that?

369
00:20:43,800 --> 00:20:47,120
Because demand moves faster than formal delivery in most growing companies.

370
00:20:47,120 --> 00:20:51,720
The business changes quickly, exceptions appear, policies shift, and reporting asks multiply

371
00:20:51,720 --> 00:20:55,440
while customers pressure timelines and leadership wants answers now.

372
00:20:55,440 --> 00:21:00,000
But the official part for process change usually moves through prioritization meetings, resource

373
00:21:00,000 --> 00:21:03,600
limits, security reviews, and long release cycles.

374
00:21:03,600 --> 00:21:07,200
So the organization develops two speeds, the formal speed and the survival speed.

375
00:21:07,200 --> 00:21:09,320
Excel lives in the gap between them.

376
00:21:09,320 --> 00:21:11,920
That is why I keep calling this structural compensation.

377
00:21:11,920 --> 00:21:16,080
We are not watching careless teams ignore a process, but rather we are watching the company

378
00:21:16,080 --> 00:21:21,360
compensate for the fact that its formal delivery model cannot keep up with its operating reality.

379
00:21:21,360 --> 00:21:25,280
The spreadsheet becomes a pressure valve, the inbox becomes a rooting engine, and the

380
00:21:25,280 --> 00:21:27,320
person becomes the integration layer.

381
00:21:27,320 --> 00:21:31,120
Because the immediate problem gets solved, the work around earns legitimacy and eventually

382
00:21:31,120 --> 00:21:32,800
hardens into the new standard.

383
00:21:32,800 --> 00:21:36,840
Then it becomes permanent, a local tracker becomes the real tracker, a temporary file becomes

384
00:21:36,840 --> 00:21:38,560
the operational source of truth.

385
00:21:38,560 --> 00:21:42,400
An unofficial approval chain becomes the one everyone actually trusts.

386
00:21:42,400 --> 00:21:46,040
And after a while nobody even describes it as a work around anymore because it just becomes

387
00:21:46,040 --> 00:21:48,280
how the company works on a daily basis.

388
00:21:48,280 --> 00:21:51,120
That normalization is what makes this so hard to unwind.

389
00:21:51,120 --> 00:21:55,080
Once a work around has history, people start defending it for rational reasons.

390
00:21:55,080 --> 00:21:58,800
They know where the formula is set, they trust the outputs they have learned to interpret

391
00:21:58,800 --> 00:22:02,160
and they fear disruption more than they fear fragility.

392
00:22:02,160 --> 00:22:06,120
Fragility is still mostly invisible on normal days while disruption is immediate in public.

393
00:22:06,120 --> 00:22:10,040
So even smart people who know this is not ideal keep rebuilding the same pattern because

394
00:22:10,040 --> 00:22:13,240
it is still the shortest path from blockage to motion.

395
00:22:13,240 --> 00:22:17,240
From a business angle, local optimization keeps winning over structural clarity.

396
00:22:17,240 --> 00:22:22,640
And local optimization is seductive because it produces fast relief while pushing complexity

397
00:22:22,640 --> 00:22:24,520
outward to other departments.

398
00:22:24,520 --> 00:22:29,160
The team that fixes its own issue today often transfers risk to the wider business tomorrow,

399
00:22:29,160 --> 00:22:32,760
such as when a spreadsheet helps procurement move but leaves finance with another version

400
00:22:32,760 --> 00:22:34,160
to reconcile.

401
00:22:34,160 --> 00:22:38,040
The email loop helps operations escalate a problem but nobody else can see the status

402
00:22:38,040 --> 00:22:42,720
cleanly and the manual patch helps one manager control risk while the company loses its shared

403
00:22:42,720 --> 00:22:44,040
operating picture.

404
00:22:44,040 --> 00:22:46,800
So the work around feels efficient where it is built.

405
00:22:46,800 --> 00:22:50,360
Even while it weakens the architecture around it, that is why telling people to stop using

406
00:22:50,360 --> 00:22:52,000
Excel rarely works.

407
00:22:52,000 --> 00:22:56,000
You are trying to remove compensation before the underlying constraint is addressed.

408
00:22:56,000 --> 00:23:00,160
If the official route still feels slow or opaque or hard to change, people will simply rebuild

409
00:23:00,160 --> 00:23:01,840
the shadow path somewhere else.

410
00:23:01,840 --> 00:23:06,600
Maybe not in Excel but in teams chats, SharePoint lists, personal notes or small apps with no

411
00:23:06,600 --> 00:23:07,600
oversight.

412
00:23:07,600 --> 00:23:09,320
The form changes but the pattern stays.

413
00:23:09,320 --> 00:23:11,960
And once you see that the next part becomes unavoidable.

414
00:23:11,960 --> 00:23:15,560
This is not just a business discipline problem, it is a backlog problem because the reason

415
00:23:15,560 --> 00:23:19,280
these work around keep winning is that the central response is too slow to absorb the

416
00:23:19,280 --> 00:23:21,440
demand the business is already generating.

417
00:23:21,440 --> 00:23:25,160
Why central IT cannot solve this by itself?

418
00:23:25,160 --> 00:23:28,280
So now we get to the part where a lot of leaders reach for the obvious answer.

419
00:23:28,280 --> 00:23:32,120
They assume that because the spreadsheet spread due to a lack of structure, central IT

420
00:23:32,120 --> 00:23:36,200
should step in, clean it up, rebuild the process properly and pull everything back under

421
00:23:36,200 --> 00:23:37,200
control.

422
00:23:37,200 --> 00:23:40,760
That sounds sensible on paper, it also breaks on contact with how most companies actually

423
00:23:40,760 --> 00:23:45,080
operate because central IT is not failing here because the people are weak or the intentions

424
00:23:45,080 --> 00:23:50,720
are wrong but rather because central IT is usually overloaded for structural reasons.

425
00:23:50,720 --> 00:23:55,040
And grows across every function at once, with procurement needing a workflow fix and finance

426
00:23:55,040 --> 00:24:00,040
wanting cleaner controls while HR needs better intake and operations once exception handling.

427
00:24:00,040 --> 00:24:03,920
All of it arrives through one funnel that was never built to absorb every process change

428
00:24:03,920 --> 00:24:06,440
the business can generate, so queues form.

429
00:24:06,440 --> 00:24:10,200
Then the queue becomes the real process, a request for small workflow improvement weights

430
00:24:10,200 --> 00:24:14,600
behind a larger platform project and a departmental pain point gets classified as important

431
00:24:14,600 --> 00:24:15,800
but not urgent.

432
00:24:15,800 --> 00:24:20,440
A workaround looks temporary so it never beats the project with high budget visibility.

433
00:24:20,440 --> 00:24:24,440
And the business learns very quickly that asking for formal delivery means waiting longer than

434
00:24:24,440 --> 00:24:26,200
the problem will tolerate.

435
00:24:26,200 --> 00:24:29,920
That is the point where people stop waiting, not because they reject IT, because the work

436
00:24:29,920 --> 00:24:31,320
still has to move.

437
00:24:31,320 --> 00:24:35,680
If a team has to choose between architectural correctness in 4 months or operational movement

438
00:24:35,680 --> 00:24:39,320
this afternoon, they will usually choose movement that choices rational inside the local

439
00:24:39,320 --> 00:24:43,160
context even when it creates wider risk for the organization.

440
00:24:43,160 --> 00:24:47,120
So they build around the backlog with files, inboxes and manual routing and each local

441
00:24:47,120 --> 00:24:51,640
fix becomes evidence that the business can survive without formal delivery for at least one

442
00:24:51,640 --> 00:24:52,720
more quarter.

443
00:24:52,720 --> 00:24:56,120
But survival is not scale and this is where central IT gets trapped.

444
00:24:56,120 --> 00:24:59,720
The more the business works around the queue, the less visible the real demand becomes.

445
00:24:59,720 --> 00:25:04,040
IT sees fewer formal requests than the company actually needs, while the business sees IT

446
00:25:04,040 --> 00:25:06,880
as too slow to matter for process level change.

447
00:25:06,880 --> 00:25:11,400
That gap widens over time and both sides start telling incomplete stories to justify their

448
00:25:11,400 --> 00:25:12,600
positions.

449
00:25:12,600 --> 00:25:15,320
IT says to submit a request and follow the process.

450
00:25:15,320 --> 00:25:19,120
The business says they did that before and by the time the solution came back the problem

451
00:25:19,120 --> 00:25:20,120
had already changed.

452
00:25:20,120 --> 00:25:23,760
Both are telling the truth from where they sit, but the design between them is broken.

453
00:25:23,760 --> 00:25:26,080
Now map that to a company like Contoso.

454
00:25:26,080 --> 00:25:30,400
Procurement does not need a two year transformation program to fix one approval path and finance

455
00:25:30,400 --> 00:25:35,760
does not need a major ERP initiative to gain a clean audit trail on threshold exceptions.

456
00:25:35,760 --> 00:25:40,160
HR does not need a custom development team to remove email from a simple request flow

457
00:25:40,160 --> 00:25:42,880
because these are not always big software problems.

458
00:25:42,880 --> 00:25:47,320
Often they are medium size process problems trapped inside large delivery machinery.

459
00:25:47,320 --> 00:25:51,760
So when leaders ask why shadow systems keep appearing, I think the answer is plain.

460
00:25:51,760 --> 00:25:55,440
Citizen development already exists, but it is just happening in the least governable

461
00:25:55,440 --> 00:25:56,720
places possible.

462
00:25:56,720 --> 00:26:00,200
In Excel in email, in private logic no one can inspect.

463
00:26:00,200 --> 00:26:03,560
That means the real strategic question is not whether the business will build because

464
00:26:03,560 --> 00:26:05,680
the business is already building every single day.

465
00:26:05,680 --> 00:26:10,440
The real question is where that building happens, under what rules, with what visibility

466
00:26:10,440 --> 00:26:13,640
and with what escalation path when the risk level changes.

467
00:26:13,640 --> 00:26:16,400
This is why central IT cannot solve the issue by itself.

468
00:26:16,400 --> 00:26:20,600
Not because IT should step back because IT acting alone as the single delivery engine for

469
00:26:20,600 --> 00:26:24,040
every process adaptation becomes another single point of failure.

470
00:26:24,040 --> 00:26:27,120
From a system perspective that model does not remove shadow systems.

471
00:26:27,120 --> 00:26:28,120
It produces them.

472
00:26:28,120 --> 00:26:29,600
The queue creates the workaround.

473
00:26:29,600 --> 00:26:33,760
The workaround creates hidden architecture, hidden architecture creates risk.

474
00:26:33,760 --> 00:26:36,600
And then leadership asks IT to clean up a mess.

475
00:26:36,600 --> 00:26:38,880
The delivery model helped generate in the first place.

476
00:26:38,880 --> 00:26:43,160
So the answer cannot be pure centralization, but it also cannot be unmanaged freedom because

477
00:26:43,160 --> 00:26:47,120
then you just rebuild the same problem with shinier tools and faster mistakes.

478
00:26:47,120 --> 00:26:51,000
What we need is a different operating stance, one that accepts business-led building as

479
00:26:51,000 --> 00:26:55,720
normal, accepts governance as necessary, and stops pretending that one central backlog

480
00:26:55,720 --> 00:26:58,760
can carry the full adaptive load of a modern company.

481
00:26:58,760 --> 00:27:01,960
Which means the next step is to name the architecture honestly.

482
00:27:01,960 --> 00:27:06,040
Because once we do that, Excel stops looking like a harmless tool choice and starts looking

483
00:27:06,040 --> 00:27:07,880
like what it really became.

484
00:27:07,880 --> 00:27:10,400
And unofficial process runtime.

485
00:27:10,400 --> 00:27:12,880
The Excel shadow system explained as architecture.

486
00:27:12,880 --> 00:27:14,240
So let's name this properly.

487
00:27:14,240 --> 00:27:17,240
What the team at Contoso built isn't just a messy collection of files.

488
00:27:17,240 --> 00:27:18,240
It's an architecture.

489
00:27:18,240 --> 00:27:22,400
It might be unofficial and brittle, but it still performs every core function a real operating

490
00:27:22,400 --> 00:27:23,640
system has to handle.

491
00:27:23,640 --> 00:27:27,680
It captures inputs, roots work, stores the current state, and distributes information to

492
00:27:27,680 --> 00:27:28,680
the right people.

493
00:27:28,680 --> 00:27:31,400
It even handles exceptions and produces final outputs.

494
00:27:31,400 --> 00:27:35,320
The only real difference is that it does all of this without any governance, visibility

495
00:27:35,320 --> 00:27:38,160
or a reliable way to control the outcome.

496
00:27:38,160 --> 00:27:41,760
That distinction matters because if we keep blaming Excel for the problem, we're staying

497
00:27:41,760 --> 00:27:43,240
too close to the surface.

498
00:27:43,240 --> 00:27:44,680
Excel isn't the problem on its own.

499
00:27:44,680 --> 00:27:47,600
The problem is using Excel as a process runtime.

500
00:27:47,600 --> 00:27:52,440
A spreadsheet used for a quick analysis or a temporary calculation is perfectly normal.

501
00:27:52,440 --> 00:27:58,080
It's fine to use a file to model scenarios, compare options or just inspect some data.

502
00:27:58,080 --> 00:28:01,640
But once that file becomes the only place where the process state lives, where approvals

503
00:28:01,640 --> 00:28:06,080
are just inferred and where version history has to stand in for a real audit trail, the file

504
00:28:06,080 --> 00:28:07,480
is no longer just a tool.

505
00:28:07,480 --> 00:28:10,760
It has become infrastructure and it's not the kind of infrastructure you want to rely

506
00:28:10,760 --> 00:28:11,760
on.

507
00:28:11,760 --> 00:28:14,080
Now map the architecture at Contoso in plain terms.

508
00:28:14,080 --> 00:28:17,800
The file acts like a database, but it lacks any reliable state management.

509
00:28:17,800 --> 00:28:22,080
The inbox acts like a workflow engine, yet it has no enforced rooting logic to keep things

510
00:28:22,080 --> 00:28:23,080
moving.

511
00:28:23,080 --> 00:28:26,680
Most importantly, the people end up acting like integration layers because they have to

512
00:28:26,680 --> 00:28:30,600
move context from one tool to another using nothing but memory and habit.

513
00:28:30,600 --> 00:28:32,960
What is the shadow system in one sentence?

514
00:28:32,960 --> 00:28:37,440
Files become unofficial databases, inboxes become workflow engines and people become the

515
00:28:37,440 --> 00:28:38,440
middleware.

516
00:28:38,440 --> 00:28:41,480
Once you see it that way, the business risk is much easier to explain.

517
00:28:41,480 --> 00:28:44,760
There is no stable source of truth because the state of the work is fragmented across a

518
00:28:44,760 --> 00:28:45,840
dozen hard drives.

519
00:28:45,840 --> 00:28:50,200
There is no clean access model because files get forwarded based on whoever is available

520
00:28:50,200 --> 00:28:51,200
at the moment.

521
00:28:51,200 --> 00:28:55,160
There isn't even any real policy logic because thresholds and exceptions live entirely

522
00:28:55,160 --> 00:28:57,760
in the interpretation of the person reading the email.

523
00:28:57,760 --> 00:29:02,000
You can't find a trustworthy audit trail because the evidence is scattered across attachments,

524
00:29:02,000 --> 00:29:03,920
replies inside conversations.

525
00:29:03,920 --> 00:29:08,280
So when leaders say but the process exists, I think the better answer is yes it exists,

526
00:29:08,280 --> 00:29:11,560
but the runtime is happening entirely outside the governed layer.

527
00:29:11,560 --> 00:29:15,120
That creates a very specific kind of business illusion where the company looks digital on

528
00:29:15,120 --> 00:29:16,120
the surface.

529
00:29:16,120 --> 00:29:21,040
People are using laptops, they work in Microsoft 365 and reports arrive on time for meetings.

530
00:29:21,040 --> 00:29:24,880
But underneath that digital surface, the core coordination is still analog.

531
00:29:24,880 --> 00:29:28,640
It relies on manual routing, manual checking and manual interpretation.

532
00:29:28,640 --> 00:29:33,080
The technology stack looks modern but the process behavior is still dependent on hand-carried

533
00:29:33,080 --> 00:29:34,080
context.

534
00:29:34,080 --> 00:29:36,840
And this is why the phrase shadow system is so useful.

535
00:29:36,840 --> 00:29:39,640
It isn't just hidden work, it is hidden architecture.

536
00:29:39,640 --> 00:29:43,640
This is an operating layer that business depends on every day, but it's one they cannot

537
00:29:43,640 --> 00:29:47,680
properly see, measure or secure and why is that dangerous because architecture doesn't

538
00:29:47,680 --> 00:29:50,640
stop affecting business outcomes just because it's unofficial.

539
00:29:50,640 --> 00:29:53,440
The company still pays for every weakness in that design.

540
00:29:53,440 --> 00:29:58,560
It pays in delays when the state of a project is unclear and it pays in rework when context

541
00:29:58,560 --> 00:30:00,040
gets lost between steps.

542
00:30:00,040 --> 00:30:03,920
It pays in compliance risk when evidence can't be reconstructed and it pays in concentration

543
00:30:03,920 --> 00:30:07,000
risk when one person becomes the only translator for the whole system.

544
00:30:07,000 --> 00:30:09,360
The system is doing exactly what it was set up to do.

545
00:30:09,360 --> 00:30:12,160
It just isn't set up for what the business actually needs right now.

546
00:30:12,160 --> 00:30:14,600
That is why I want to remove blame from the conversation for a moment.

547
00:30:14,600 --> 00:30:18,360
The Excel shadow system isn't proof that Conto is so hired careless people.

548
00:30:18,360 --> 00:30:22,200
It's proof that the business built an operating layer faster than its formal architecture

549
00:30:22,200 --> 00:30:23,680
could evolve to support it.

550
00:30:23,680 --> 00:30:24,880
That is a system outcome.

551
00:30:24,880 --> 00:30:27,040
Demand kept moving and work had to flow.

552
00:30:27,040 --> 00:30:30,440
So the company assembled a runtime from the tools they had closest at hand.

553
00:30:30,440 --> 00:30:32,960
It was useful at first, but it's fragile at scale.

554
00:30:32,960 --> 00:30:36,280
Once we say that clearly the conversation improves, we stop asking how to stop people

555
00:30:36,280 --> 00:30:39,720
from using spreadsheets and start asking what architecture should carry this process

556
00:30:39,720 --> 00:30:40,720
instead.

557
00:30:40,720 --> 00:30:43,880
That is a much better question because it shifts the discussion from tool preference

558
00:30:43,880 --> 00:30:45,120
to operating design.

559
00:30:45,120 --> 00:30:49,000
Once we name the shadow system as architecture, we can finally compare it with a governed

560
00:30:49,000 --> 00:30:50,240
one.

561
00:30:50,240 --> 00:30:53,400
It's a great power platform changes at the structural level.

562
00:30:53,400 --> 00:30:56,680
So once we name the shadow system, honestly, the next question is straightforward.

563
00:30:56,680 --> 00:31:01,160
What changes when Contoso stops running processes through files and mail and starts running

564
00:31:01,160 --> 00:31:04,200
them through a governed power platform architecture?

565
00:31:04,200 --> 00:31:05,840
The first change isn't cosmetic.

566
00:31:05,840 --> 00:31:07,360
It is structural.

567
00:31:07,360 --> 00:31:11,360
Power platform shifts the company from hidden manual coordination to observable process

568
00:31:11,360 --> 00:31:12,360
behavior.

569
00:31:12,360 --> 00:31:14,840
That sounds technical, but the business effect is simple.

570
00:31:14,840 --> 00:31:18,960
Work stops depending on people to carry the state from one step to the next because the

571
00:31:18,960 --> 00:31:22,040
architecture starts carrying more of that load itself.

572
00:31:22,040 --> 00:31:23,440
Take Power Apps first.

573
00:31:23,440 --> 00:31:27,240
Instead of a request beginning as an email with a few unwritten assumptions, Power Apps

574
00:31:27,240 --> 00:31:29,800
gives the business a structured entry point.

575
00:31:29,800 --> 00:31:33,720
Required fields are enforced, inputs are guided and roles only see what they need to see.

576
00:31:33,720 --> 00:31:38,120
The requester doesn't have to guess which version of a spreadsheet to use and the receiving

577
00:31:38,120 --> 00:31:41,280
team doesn't have to reconstruct intent from a messy email.

578
00:31:41,280 --> 00:31:44,800
The process starts with cleaner data because the architecture shapes the interaction at the

579
00:31:44,800 --> 00:31:45,800
front door.

580
00:31:45,800 --> 00:31:47,120
That alone changes a lot.

581
00:31:47,120 --> 00:31:49,720
Many downstream problems don't actually begin downstream.

582
00:31:49,720 --> 00:31:53,640
They begin at intake where ambiguity enters the process and then spreads like a virus.

583
00:31:53,640 --> 00:31:55,080
Then you add Power Automate.

584
00:31:55,080 --> 00:31:58,800
This is where routing stops living inhabit and starts living in logic that the business

585
00:31:58,800 --> 00:32:00,120
can actually inspect.

586
00:32:00,120 --> 00:32:05,000
Approval parts can follow specific thresholds or departments and notifications happen because

587
00:32:05,000 --> 00:32:09,200
the process changed state, not because somebody remembered to forward a message.

588
00:32:09,200 --> 00:32:13,960
Escalations trigger automatically based on elapsed time, which makes ownership and waiting

589
00:32:13,960 --> 00:32:15,720
times visible to everyone.

590
00:32:15,720 --> 00:32:20,600
Now the company can see whether a request is pending manager review or a finance validation.

591
00:32:20,600 --> 00:32:24,360
That is a world away from sending messages around asking if anyone knows where a specific

592
00:32:24,360 --> 00:32:25,720
file went.

593
00:32:25,720 --> 00:32:30,840
From a process perspective, Power Automate turns invisible coordination into orchestration.

594
00:32:30,840 --> 00:32:34,200
Once orchestration is visible, management gets a different kind of control.

595
00:32:34,200 --> 00:32:37,920
It isn't control through chasing people, it's control through design.

596
00:32:37,920 --> 00:32:39,080
Then there is Power BI.

597
00:32:39,080 --> 00:32:42,960
A lot of people treat Power BI as just a reporting layer and while it is that it matters

598
00:32:42,960 --> 00:32:47,200
here because it gives the business shared visibility into the flow, you can see the backlog,

599
00:32:47,200 --> 00:32:51,400
the aging and the bottlenecks without debating which local file represents reality.

600
00:32:51,400 --> 00:32:54,880
The company can monitor the operating picture from the process itself.

601
00:32:54,880 --> 00:32:58,880
That doesn't remove every data problem overnight but it changes the direction of trust.

602
00:32:58,880 --> 00:33:03,080
The process starts producing a common picture instead of forcing people to reconcile competing

603
00:33:03,080 --> 00:33:08,080
ones after the fact and where it's needed, dataverse and connected Microsoft 365 services

604
00:33:08,080 --> 00:33:10,480
provide a governed data layer underneath all of this.

605
00:33:10,480 --> 00:33:14,640
I want to be careful here because not every process needs dataverse on day one but structurally

606
00:33:14,640 --> 00:33:15,840
the option matters.

607
00:33:15,840 --> 00:33:20,120
It means the business has a place for managed data and policy or wear storage when the process

608
00:33:20,120 --> 00:33:21,120
calls for it.

609
00:33:21,120 --> 00:33:25,400
That is a very different foundation from scattering business critical information across attachments

610
00:33:25,400 --> 00:33:26,720
and local copies.

611
00:33:26,720 --> 00:33:29,720
So the shift isn't really from Excel to Power Platform as tools.

612
00:33:29,720 --> 00:33:32,800
It is a shift from an unofficial runtime to a governed runtime.

613
00:33:32,800 --> 00:33:33,960
That is the entire point.

614
00:33:33,960 --> 00:33:38,040
The file no longer acts like a database, the inbox no longer acts like the workflow engine

615
00:33:38,040 --> 00:33:41,120
and the person no longer acts like the integration layer.

616
00:33:41,120 --> 00:33:45,000
Instead the company starts moving towards structured intake, rule based orchestration and

617
00:33:45,000 --> 00:33:46,480
shared visibility.

618
00:33:46,480 --> 00:33:50,560
That creates something the shadow system could never offer consistently.

619
00:33:50,560 --> 00:33:54,440
Observable flow means you can see where work sits and why it's all.

620
00:33:54,440 --> 00:33:57,720
You know who owns the next action and which exceptions keep repeating.

621
00:33:57,720 --> 00:34:01,320
You can finally see whether the architecture is actually supporting the business or forcing

622
00:34:01,320 --> 00:34:03,120
people to compensate for its failures.

623
00:34:03,120 --> 00:34:05,760
Once you can see that improvement stops being guesswork.

624
00:34:05,760 --> 00:34:08,600
And this is why I don't frame Power Platform as a tool story.

625
00:34:08,600 --> 00:34:10,840
It is an operating architecture story.

626
00:34:10,840 --> 00:34:12,960
Contoso isn't just replacing spreadsheets.

627
00:34:12,960 --> 00:34:17,560
They are redesigning where process logic lives and where management gets visibility.

628
00:34:17,560 --> 00:34:20,840
Speed improves of course, but the deeper gain is that the business starts running on an

629
00:34:20,840 --> 00:34:22,920
architecture it can actually govern.

630
00:34:22,920 --> 00:34:26,920
To make that concrete we need to stop speaking in general terms and look at one specific process

631
00:34:26,920 --> 00:34:30,960
inside Contoso because that is where the structural difference becomes impossible to ignore.

632
00:34:30,960 --> 00:34:33,840
The procurement approval process before redesign.

633
00:34:33,840 --> 00:34:37,680
Let's take one specific process and look at it under a microscope because this is the

634
00:34:37,680 --> 00:34:42,480
exact moment where architecture stops being a slide deck and starts being a reality.

635
00:34:42,480 --> 00:34:45,840
At Contoso the procurement approval process sounds completely harmless when you describe

636
00:34:45,840 --> 00:34:47,040
it in a meeting.

637
00:34:47,040 --> 00:34:50,720
Someone needs to buy something so they send a request, the manager signs off, finance checks

638
00:34:50,720 --> 00:34:54,200
the numbers and procurement confirms the vendor before the order moves.

639
00:34:54,200 --> 00:34:56,280
That is the story people tell themselves.

640
00:34:56,280 --> 00:35:00,080
And on a whiteboard it looks clean enough to pass for a control business system.

641
00:35:00,080 --> 00:35:02,560
But the lived process is a different animal entirely.

642
00:35:02,560 --> 00:35:06,960
A request starts their day by hunting for the latest spreadsheet template or at least

643
00:35:06,960 --> 00:35:11,200
what they hope is the latest version, usually digging through old emails, buried teams, chats

644
00:35:11,200 --> 00:35:15,200
or a shared folder containing five files with nearly identical names.

645
00:35:15,200 --> 00:35:19,840
They manually enter the supplier, the cost center, the expected cost and the business justification

646
00:35:19,840 --> 00:35:23,840
because different teams have learned to tolerate different gaps over the years.

647
00:35:23,840 --> 00:35:27,920
Some fields stay empty and then they just attach that file to an email and fire it off to their

648
00:35:27,920 --> 00:35:29,280
manager.

649
00:35:29,280 --> 00:35:32,820
That very first step creates immediate system instability because the process doesn't start

650
00:35:32,820 --> 00:35:34,200
in a controlled environment.

651
00:35:34,200 --> 00:35:38,440
It starts with file discovery and local interpretation, which means the foundation is built on whatever

652
00:35:38,440 --> 00:35:41,520
the requester happens to find in their inbox that morning.

653
00:35:41,520 --> 00:35:43,840
Then the manager opens that attachment to see what's going on.

654
00:35:43,840 --> 00:35:47,560
If the request looks simple, they might just hit reply with a quick approved.

655
00:35:47,560 --> 00:35:51,840
But if the price tag looks high, they might loop in finance or ask procurement a few informal

656
00:35:51,840 --> 00:35:53,440
questions before they commit.

657
00:35:53,440 --> 00:35:57,040
If a single field is missing, the file gets bounced back and sometimes the manager just edits

658
00:35:57,040 --> 00:36:01,760
the spreadsheet themselves or leaves a few cryptic comments in the body of the email.

659
00:36:01,760 --> 00:36:05,560
At this point, the request has already fragmented across three or four different channels.

660
00:36:05,560 --> 00:36:07,360
The spreadsheet holds a little bit of the truth.

661
00:36:07,360 --> 00:36:10,040
The email thread holds another piece of the story.

662
00:36:10,040 --> 00:36:14,360
And the people involved are forced to carry the rest of the status in their own heads.

663
00:36:14,360 --> 00:36:18,640
From there, the six-step approval path that Contoso doesn't actually run on enforced logic,

664
00:36:18,640 --> 00:36:20,760
but rather it runs on tribal knowledge and habit.

665
00:36:20,760 --> 00:36:24,560
There is a manager review, a finance threshold check, and a procurement validation, along

666
00:36:24,560 --> 00:36:29,320
with occasional visits to legal or operations depending on what is being ordered.

667
00:36:29,320 --> 00:36:33,680
Everyone in the building can explain the general flow, but the actual route the file takes

668
00:36:33,680 --> 00:36:38,200
depends on individual judgment calls and whoever happens to notice a missing detail.

669
00:36:38,200 --> 00:36:41,200
This means that status is never truly visible at a system level.

670
00:36:41,200 --> 00:36:45,080
The person who submitted the request has no idea if their file is waiting for a signature

671
00:36:45,080 --> 00:36:49,600
sitting in a threshold review or just buried under a hundred other unread messages in

672
00:36:49,600 --> 00:36:51,200
someone's inbox.

673
00:36:51,200 --> 00:36:55,400
To get an answer, they have to chase it manually by sending follow-ups, making phone calls,

674
00:36:55,400 --> 00:36:58,400
and asking colleagues if they've seen the request lately.

675
00:36:58,400 --> 00:37:02,840
Approvers often reply without knowing the full history, finance receives outdated versions

676
00:37:02,840 --> 00:37:06,600
of the file, and procurement eventually pauses the whole thing because the numbers don't

677
00:37:06,600 --> 00:37:07,600
reconcile.

678
00:37:07,600 --> 00:37:11,640
This is where the system starts burning management capacity far beyond the value of the

679
00:37:11,640 --> 00:37:12,960
actual transaction.

680
00:37:12,960 --> 00:37:17,080
A standard purchase request should never require this much detective work to complete.

681
00:37:17,080 --> 00:37:20,560
At Contoso, detective work was the only way things got done.

682
00:37:20,560 --> 00:37:24,560
Because there is no validation at the front door, downstream teams are constantly finding problems

683
00:37:24,560 --> 00:37:26,080
far too late in the game.

684
00:37:26,080 --> 00:37:30,240
The vendor name is wrong, the budget estimate was off, or the business reason is too vague

685
00:37:30,240 --> 00:37:31,800
for a policy review.

686
00:37:31,800 --> 00:37:33,520
And so the request loops backward.

687
00:37:33,520 --> 00:37:36,600
This isn't a rare exception but a regular feature of the environment.

688
00:37:36,600 --> 00:37:40,120
When the leadership at Contoso finally sat down to measure this mess honestly, three

689
00:37:40,120 --> 00:37:42,400
specific numbers told the whole story.

690
00:37:42,400 --> 00:37:44,080
The average cycle time was nine days.

691
00:37:44,080 --> 00:37:48,240
The rework rate sat at 22%, visibility was effectively zero unless someone decided to

692
00:37:48,240 --> 00:37:50,360
personally investigate the paper trail.

693
00:37:50,360 --> 00:37:54,160
The specific combination is important because it explains why a broken process can survive

694
00:37:54,160 --> 00:37:55,160
for years.

695
00:37:55,160 --> 00:37:58,240
It worked just well enough to keep the lights on and because orders eventually went through

696
00:37:58,240 --> 00:38:01,960
and teams compensated for the friction, the business kept moving.

697
00:38:01,960 --> 00:38:06,400
When a system still delivers an output, even a bad one, nobody feels the urge to redesign

698
00:38:06,400 --> 00:38:10,200
it until the hidden cost of that friction becomes impossible to ignore.

699
00:38:10,200 --> 00:38:13,800
Before they touched a single line of code, this is what procurement at Contoso actually

700
00:38:13,800 --> 00:38:14,800
was.

701
00:38:14,800 --> 00:38:18,840
It wasn't a governed process but a loosely connected chain of files, emails and social

702
00:38:18,840 --> 00:38:22,200
pressure that only held together because the people inside were carrying the weight that

703
00:38:22,200 --> 00:38:24,040
the architecture dropped.

704
00:38:24,040 --> 00:38:26,600
The procurement approval process after redesign.

705
00:38:26,600 --> 00:38:29,960
Now let's look at what happens when you change the architecture instead of trying to change

706
00:38:29,960 --> 00:38:30,960
the people.

707
00:38:30,960 --> 00:38:34,760
Contoso didn't start this journey by launching a massive transformation program that promised

708
00:38:34,760 --> 00:38:35,760
to change the world.

709
00:38:35,760 --> 00:38:40,400
They started with one process, one owner and one governed environment, with the very specific

710
00:38:40,400 --> 00:38:44,200
goal of stopping email and spreadsheets from acting as the systems engine.

711
00:38:44,200 --> 00:38:48,120
The first thing you notice is that the entry point has completely changed.

712
00:38:48,120 --> 00:38:52,720
Instead of hunting through folders for a template, the requester opens a power app designed specifically

713
00:38:52,720 --> 00:38:54,120
for procurement intake.

714
00:38:54,120 --> 00:38:57,600
The fields are structured and the rules are hard coded so the required information is

715
00:38:57,600 --> 00:39:01,960
enforced the moment someone hits submit, rather than being discovered three days later by

716
00:39:01,960 --> 00:39:03,960
a frustrated finance clerk.

717
00:39:03,960 --> 00:39:08,240
Supplier details, cost centers and business justifications all enter through one controlled

718
00:39:08,240 --> 00:39:13,080
front door and if a request is incomplete, it doesn't drift into the system half-formed.

719
00:39:13,080 --> 00:39:17,440
That single shift removes a massive amount of noise from the system because ambiguity is

720
00:39:17,440 --> 00:39:20,400
no longer allowed to enter the workflow disguised as progress.

721
00:39:20,400 --> 00:39:24,200
Once that data is in, power automate takes over the path that the inbox used to try and

722
00:39:24,200 --> 00:39:25,200
improvise.

723
00:39:25,200 --> 00:39:28,880
Approval routing is no longer a matter of habit or who happens to be copied on a thread.

724
00:39:28,880 --> 00:39:32,560
The flow automatically checks the dollar amount, the request type and the business area

725
00:39:32,560 --> 00:39:34,680
against the latest policy conditions.

726
00:39:34,680 --> 00:39:39,120
A low value order might just go to a manager while a high threshold request triggers a finance

727
00:39:39,120 --> 00:39:43,440
review and a supplier exception might branch off into a legal check without anyone needing

728
00:39:43,440 --> 00:39:44,920
to remember the rules.

729
00:39:44,920 --> 00:39:49,800
The logic is now visible, it is repeatable and most importantly, it is reviewable by anyone

730
00:39:49,800 --> 00:39:51,000
with the right access.

731
00:39:51,000 --> 00:39:54,680
This matters because for the first time the process actually knows where it is.

732
00:39:54,680 --> 00:39:58,720
The system can tell the request and the owner exactly where the bottleneck is, whether

733
00:39:58,720 --> 00:40:02,240
it's pending a manager's signature or sitting in exception handling.

734
00:40:02,240 --> 00:40:05,640
Nobody has to reconstruct the history of a request from scattered signals anymore because

735
00:40:05,640 --> 00:40:08,680
the architecture carries that state as a primary function.

736
00:40:08,680 --> 00:40:13,120
Since the architecture is now doing the heavy lifting, the way the team handles escalations

737
00:40:13,120 --> 00:40:14,120
changes as well.

738
00:40:14,120 --> 00:40:18,120
The request sits idle for too long, the flow sends a notification to the right person based

739
00:40:18,120 --> 00:40:19,560
on the actual time elapsed.

740
00:40:19,560 --> 00:40:23,320
If an approval takes longer than the target window, that delay becomes a data point in

741
00:40:23,320 --> 00:40:27,280
the system, rather than just a source of frustration for the person waiting.

742
00:40:27,280 --> 00:40:31,200
If a submission needs a correction, that work happens inside the govern path instead of

743
00:40:31,200 --> 00:40:35,920
spawning a new version of a file and a sidechain of confusing emails, then you lay up Power BI

744
00:40:35,920 --> 00:40:37,240
on top of that foundation.

745
00:40:37,240 --> 00:40:41,280
For the first time in the company's history, Contoso can see their procurement process

746
00:40:41,280 --> 00:40:45,200
as a living picture of their operations instead of a monthly post-mortem.

747
00:40:45,200 --> 00:40:49,320
They can see the backlog, the aging requests and the approval bottlenecks in near real time,

748
00:40:49,320 --> 00:40:53,280
which allows finance to see exactly where the threshold delays are happening.

749
00:40:53,280 --> 00:40:57,040
Leaders no longer have to guess if the process is actually getting faster or if they've

750
00:40:57,040 --> 00:40:59,400
just moved the queue to a different department.

751
00:40:59,400 --> 00:41:03,640
This fundamentally shifts the management conversation because meetings no longer start with a debate

752
00:41:03,640 --> 00:41:06,200
over which spreadsheet is the most recent.

753
00:41:06,200 --> 00:41:10,080
Instead, the conversation starts with where the friction is located and what the flow

754
00:41:10,080 --> 00:41:12,360
data is telling them about the system's health.

755
00:41:12,360 --> 00:41:16,360
Within 90 days of making these changes, the results were no longer just a theory on a slide.

756
00:41:16,360 --> 00:41:19,920
The average cycle time crashed from 9 days down to just 2.5.

757
00:41:19,920 --> 00:41:23,320
Rework fell below 5% because the data was clean from the start.

758
00:41:23,320 --> 00:41:27,760
The audit trail became a permanent part of the record, showing exactly who approved what

759
00:41:27,760 --> 00:41:30,760
and when the request moved from one stage to the next.

760
00:41:30,760 --> 00:41:32,720
But here is the most important part of the story.

761
00:41:32,720 --> 00:41:35,880
Contoso didn't need any more heroics from their staff to make this work.

762
00:41:35,880 --> 00:41:39,600
They didn't need a specific person to stay late to keep a file alive.

763
00:41:39,600 --> 00:41:43,920
They didn't need requesters to spend their afternoons chasing status updates or managers

764
00:41:43,920 --> 00:41:46,680
to guess the next step from a buried email thread.

765
00:41:46,680 --> 00:41:50,400
The work still involved human beings and their judgment still mattered, but the people inside

766
00:41:50,400 --> 00:41:54,160
the process were no longer acting as the glue holding the whole thing together.

767
00:41:54,160 --> 00:41:55,480
That is the structural difference.

768
00:41:55,480 --> 00:41:59,400
The architecture now carries the coordination load, which means the business can move faster

769
00:41:59,400 --> 00:42:03,160
without losing control and it can maintain control without slowing everyone down with manual

770
00:42:03,160 --> 00:42:04,160
checks.

771
00:42:04,160 --> 00:42:08,000
When I hear leaders look at a project like this and say they automated approvals, I think

772
00:42:08,000 --> 00:42:10,640
they are missing the real point of the transformation.

773
00:42:10,640 --> 00:42:15,160
What Contoso actually did was move from a world of hidden coordination to a world of

774
00:42:15,160 --> 00:42:16,160
governed flow.

775
00:42:16,160 --> 00:42:20,680
Once you make that shift, the business is no longer just surviving through invisible human

776
00:42:20,680 --> 00:42:26,400
effort, but it is operating through an architecture that the leadership can finally see and manage.

777
00:42:26,400 --> 00:42:29,000
This is not automation for its own sake.

778
00:42:29,000 --> 00:42:33,360
Now this is where a lot of leaders misread what just changed at Contoso because they look

779
00:42:33,360 --> 00:42:35,800
at the outcome and reduce it to a familiar phrase.

780
00:42:35,800 --> 00:42:37,480
We automated the approvals.

781
00:42:37,480 --> 00:42:38,960
It is true, but it is incomplete.

782
00:42:38,960 --> 00:42:42,000
If all you see is speed, you miss the structural gain.

783
00:42:42,000 --> 00:42:44,640
The deeper change is not that requests move faster.

784
00:42:44,640 --> 00:42:48,120
The deeper change is that the business can finally see the flow it depends on and once

785
00:42:48,120 --> 00:42:54,080
flow becomes visible, management stops operating through guesswork, memory and escalation theatre.

786
00:42:54,080 --> 00:42:57,120
That matters because automation on its own can still create a mess.

787
00:42:57,120 --> 00:43:00,800
You can automate a bad path, you can speed up the wrong hand off and you can push broken

788
00:43:00,800 --> 00:43:03,240
logic through a faster channel and call it progress.

789
00:43:03,240 --> 00:43:04,760
I've seen that happen more than once.

790
00:43:04,760 --> 00:43:09,040
A company replaces email with a flow but keeps unclear ownership or it builds an app while

791
00:43:09,040 --> 00:43:12,920
the policy rules still live inside documents and tribal knowledge.

792
00:43:12,920 --> 00:43:16,240
Work moves faster for a while, yet the core ambiguity stays in place.

793
00:43:16,240 --> 00:43:19,360
The interface changed, but the operating truth did not.

794
00:43:19,360 --> 00:43:21,680
That is not what happened in the Contoso redesign.

795
00:43:21,680 --> 00:43:25,760
What changed was not just the amount of manual effort, but where certainty actually came

796
00:43:25,760 --> 00:43:26,760
from.

797
00:43:26,760 --> 00:43:31,920
Before the redesign, certainty came from people checking, asking, reconciling and remembering.

798
00:43:31,920 --> 00:43:34,600
After the redesign, more certainty comes from architecture.

799
00:43:34,600 --> 00:43:39,440
The intake carries structure, the routing carries logic, the reporting carries shared visibility,

800
00:43:39,440 --> 00:43:41,040
and the audit trail carries evidence.

801
00:43:41,040 --> 00:43:43,040
So yes, cycle time dropped and that matters.

802
00:43:43,040 --> 00:43:45,200
Yes, rework fell and that matters too.

803
00:43:45,200 --> 00:43:48,600
But from a leadership perspective, the bigger gain is that the company no longer needs to

804
00:43:48,600 --> 00:43:51,760
spend management energy figuring out what the process is doing.

805
00:43:51,760 --> 00:43:55,760
The process starts revealing that directly, that reduces a kind of noise most businesses

806
00:43:55,760 --> 00:43:57,880
normalise without noticing.

807
00:43:57,880 --> 00:44:03,640
Status chasing, clarification loops, reconciliation meetings, manual escalations caused by uncertainty

808
00:44:03,640 --> 00:44:05,040
instead of real exception.

809
00:44:05,040 --> 00:44:09,520
Those things feel small when viewed one by one, but taken together, they drain attention

810
00:44:09,520 --> 00:44:12,680
from the people who should be improving the business instead of decoding it.

811
00:44:12,680 --> 00:44:13,680
And why is that?

812
00:44:13,680 --> 00:44:15,560
Because ambiguity creates management load.

813
00:44:15,560 --> 00:44:17,720
When ownership is unclear, leaders intervene.

814
00:44:17,720 --> 00:44:20,320
When state is unclear, analysts investigate.

815
00:44:20,320 --> 00:44:24,160
When policy application is unclear, teams pause and ask for interpretation.

816
00:44:24,160 --> 00:44:26,680
So a weak process does not only waste front line time.

817
00:44:26,680 --> 00:44:30,280
It climbs upward into coordination overhead where the cost gets more expensive fast.

818
00:44:30,280 --> 00:44:33,600
This is why I do not think the right contrast is automation versus manual work.

819
00:44:33,600 --> 00:44:37,000
The right contrast is ambiguity versus governed flow.

820
00:44:37,000 --> 00:44:40,040
Automation removes waiting where the step is already understood.

821
00:44:40,040 --> 00:44:43,840
Governance removes uncertainty about who acts under which rule, with which evidence and

822
00:44:43,840 --> 00:44:46,000
in what state the work currently sits.

823
00:44:46,000 --> 00:44:48,280
That combination changes the business conversation.

824
00:44:48,280 --> 00:44:50,560
Instead of asking, can we move this faster?

825
00:44:50,560 --> 00:44:52,120
Leaders can ask better questions.

826
00:44:52,120 --> 00:44:53,800
Where do requests age most?

827
00:44:53,800 --> 00:44:55,720
Which exception paths repeat too often?

828
00:44:55,720 --> 00:44:57,920
Which thresholds create avoidable delay?

829
00:44:57,920 --> 00:45:01,080
Where is policy generating friction because the logic is unclear?

830
00:45:01,080 --> 00:45:05,120
That is a different level of control, not control through pressure, but control through observability.

831
00:45:05,120 --> 00:45:09,160
And once a company gets that, speed and control stop looking like competing goals.

832
00:45:09,160 --> 00:45:11,400
In the Excel shadow system, they usually do compete.

833
00:45:11,400 --> 00:45:15,840
If you want speed, you bypass control, and if you want control, you add checks and create

834
00:45:15,840 --> 00:45:16,840
more delay.

835
00:45:16,840 --> 00:45:19,040
The business learns to treat governance as drag.

836
00:45:19,040 --> 00:45:21,560
In a governed architecture, that trade off softens.

837
00:45:21,560 --> 00:45:23,520
Control can travel inside the flow.

838
00:45:23,520 --> 00:45:27,840
Required fields, access boundaries, approval logic, timestamps, exception handling, and reporting

839
00:45:27,840 --> 00:45:31,160
do not have to sit outside the processes extra layers of friction.

840
00:45:31,160 --> 00:45:34,320
They can sit inside the architecture that runs the work.

841
00:45:34,320 --> 00:45:36,440
That is why this is not automation for its own sake.

842
00:45:36,440 --> 00:45:37,960
It is structural clarification.

843
00:45:37,960 --> 00:45:41,600
It is the business moving from hidden coordination to visible operations.

844
00:45:41,600 --> 00:45:45,520
And once leaders see that clearly, the next mistake becomes easier to avoid.

845
00:45:45,520 --> 00:45:50,080
Because giving people low-code tools without an operating model does not remove shadow systems.

846
00:45:50,080 --> 00:45:52,360
It just rebuilds them at higher speed.

847
00:45:52,360 --> 00:45:56,080
Why low-code fails when organizations scale tools instead of architecture?

848
00:45:56,080 --> 00:45:59,840
So now we get to the objection that shows up almost every time this conversation becomes

849
00:45:59,840 --> 00:46:00,840
serious.

850
00:46:00,840 --> 00:46:03,040
We tried low-code before and it didn't scale.

851
00:46:03,040 --> 00:46:06,840
I take that objection seriously because in a lot of companies it is true.

852
00:46:06,840 --> 00:46:10,200
People did build apps, flows, did spread, and a few teams moved fast.

853
00:46:10,200 --> 00:46:13,640
Then six months later, nobody knew which solution mattered, who owned what, which connectors

854
00:46:13,640 --> 00:46:18,400
were in use, what data was exposed, or how anything should move from experiment to production.

855
00:46:18,400 --> 00:46:22,280
The result looked like progress for a while, then felt like another mess to clean up.

856
00:46:22,280 --> 00:46:25,840
But if you look closely, low-code did not fail there.

857
00:46:25,840 --> 00:46:31,320
Or more precisely the company scaled tools without scaling the operating model around them.

858
00:46:31,320 --> 00:46:34,440
That distinction matters because otherwise leaders learn the wrong lesson.

859
00:46:34,440 --> 00:46:39,280
They see apps Brawl, Week Ownership, and Inconsistent Quality, then conclude the platform

860
00:46:39,280 --> 00:46:40,280
created chaos.

861
00:46:40,280 --> 00:46:43,720
In most cases, the platform only exposed the pattern that already existed.

862
00:46:43,720 --> 00:46:47,960
The business was already improvising outside formal delivery and low-code just gave that improvisation

863
00:46:47,960 --> 00:46:49,640
a faster and more visible form.

864
00:46:49,640 --> 00:46:51,480
So the problem is not that people can build.

865
00:46:51,480 --> 00:46:53,840
The problem is that people can build into a vacuum.

866
00:46:53,840 --> 00:46:54,840
No life cycle.

867
00:46:54,840 --> 00:46:56,320
No environment strategy.

868
00:46:56,320 --> 00:46:57,320
No clear ownership.

869
00:46:57,320 --> 00:46:58,920
No review path for risk.

870
00:46:58,920 --> 00:47:02,120
No shared standards for naming, connectors, support, or retirement.

871
00:47:02,120 --> 00:47:05,640
And once those conditions are missing, the business recreates the same shadow system we

872
00:47:05,640 --> 00:47:06,640
saw with Excel.

873
00:47:06,640 --> 00:47:10,720
Only now it happens through apps and flows instead of files and inboxes.

874
00:47:10,720 --> 00:47:14,160
That is why I think leaders need to be very careful with the sentence.

875
00:47:14,160 --> 00:47:15,720
We scaled low-code.

876
00:47:15,720 --> 00:47:18,120
In many organizations what actually happened is simpler.

877
00:47:18,120 --> 00:47:20,600
They scaled access, but they did not scale architecture.

878
00:47:20,600 --> 00:47:21,960
And those are not the same thing.

879
00:47:21,960 --> 00:47:23,760
Access means more people can create.

880
00:47:23,760 --> 00:47:28,760
Access means creation happens inside boundaries that preserve trust, supportability, and visibility

881
00:47:28,760 --> 00:47:29,760
as volume grows.

882
00:47:29,760 --> 00:47:32,520
Without that second layer, success contains the seed of failure.

883
00:47:32,520 --> 00:47:36,480
The better the tools get, the faster unmanaged expansion happens.

884
00:47:36,480 --> 00:47:40,960
One department builds a useful app, another copies the idea without understanding the connector

885
00:47:40,960 --> 00:47:41,960
risk.

886
00:47:41,960 --> 00:47:46,440
And a third automates a local approval, but stores business logic in three different places.

887
00:47:46,440 --> 00:47:51,080
Soon, there are many moving parts, yet no common view of what is live, what is risky, what

888
00:47:51,080 --> 00:47:54,480
is duplicated, and what should never have reached production.

889
00:47:54,480 --> 00:47:59,320
From a system perspective, that is not democratization, it is unmanaged distribution, and unmanaged

890
00:47:59,320 --> 00:48:02,440
distribution breaks for the same reasons shadow systems break.

891
00:48:02,440 --> 00:48:06,920
State fragments, ownership blurs, evidence weekends, support becomes personal, risk spreads

892
00:48:06,920 --> 00:48:08,240
faster than visibility.

893
00:48:08,240 --> 00:48:12,600
So when someone tells me low-code did not scale in their company, I usually want to ask

894
00:48:12,600 --> 00:48:13,840
one question first.

895
00:48:13,840 --> 00:48:16,640
What exactly scaled the platform or the permissions?

896
00:48:16,640 --> 00:48:20,640
Because if the answer is mostly permissions, then the outcome was almost predictable.

897
00:48:20,640 --> 00:48:22,760
Now map that back to business reality.

898
00:48:22,760 --> 00:48:27,200
A team builds an app because the backlog is too slow, and another team builds a similar app

899
00:48:27,200 --> 00:48:29,480
because they never knew the first one existed.

900
00:48:29,480 --> 00:48:33,320
A manager leaves and nobody knows who owns the flow, or a connector gets used in a way

901
00:48:33,320 --> 00:48:34,800
security never reviewed.

902
00:48:34,800 --> 00:48:38,560
An app solves a real problem but cannot be trusted across the business because nobody knows

903
00:48:38,560 --> 00:48:39,560
its life cycle.

904
00:48:39,560 --> 00:48:41,200
That is not a low-code failure.

905
00:48:41,200 --> 00:48:42,440
That is a governance vacuum.

906
00:48:42,440 --> 00:48:44,960
And once you name it that way, the path forward gets clearer.

907
00:48:44,960 --> 00:48:48,440
The answer is not to pull the tools back and force everything into one central queue

908
00:48:48,440 --> 00:48:49,440
again.

909
00:48:49,440 --> 00:48:51,960
It only push building back into hidden places.

910
00:48:51,960 --> 00:48:55,920
The answer is to make business-led building, legitimate, visible and bounded, which means

911
00:48:55,920 --> 00:49:00,360
low-code only works at scale when the architecture rounded answers a few basic questions.

912
00:49:00,360 --> 00:49:04,160
Who can build what, in which environment, against which data, with which review, owned

913
00:49:04,160 --> 00:49:07,480
by whom, supported how, retired when?

914
00:49:07,480 --> 00:49:11,800
If those answers stay vague, the platform becomes another acceleration layer for confusion.

915
00:49:11,800 --> 00:49:15,560
If those answers become clear, then low-code stops behaving like a risk amplifier and

916
00:49:15,560 --> 00:49:18,480
starts behaving like a governed extension of delivery capacity.

917
00:49:18,480 --> 00:49:20,600
So the lesson is not, be careful with low-code.

918
00:49:20,600 --> 00:49:24,200
The lesson is, do not confuse tool roll-out with operating design.

919
00:49:24,200 --> 00:49:28,120
Because if you scale tools without architecture, you get faster shadow systems.

920
00:49:28,120 --> 00:49:31,440
If you scale architecture with the tools, you get something very different.

921
00:49:31,440 --> 00:49:33,560
You get a platform the business can trust.

922
00:49:33,560 --> 00:49:35,000
Governance is not restriction.

923
00:49:35,000 --> 00:49:36,800
It is making scale safe.

924
00:49:36,800 --> 00:49:40,280
We need to have a more mature conversation about this because the word governance still

925
00:49:40,280 --> 00:49:43,320
triggers a defensive reaction in most boardrooms.

926
00:49:43,320 --> 00:49:46,040
When people hear that word, they don't think of safety.

927
00:49:46,040 --> 00:49:50,280
They imagine a massive slowdown filled with extra approval layers, endless forms, and more

928
00:49:50,280 --> 00:49:51,600
people saying no.

929
00:49:51,600 --> 00:49:55,360
They see a growing distance between the problem they have and the fix they need.

930
00:49:55,360 --> 00:49:59,080
If that is what governance looks like inside your organization, I completely understand why

931
00:49:59,080 --> 00:50:00,840
your teams are resisting it.

932
00:50:00,840 --> 00:50:03,520
But we have to be honest, that isn't governance working correctly.

933
00:50:03,520 --> 00:50:06,480
It's just bureaucracy trying to compensate for a lack of trust.

934
00:50:06,480 --> 00:50:10,760
Good governance does something very different by making scale safe for everyone involved.

935
00:50:10,760 --> 00:50:12,840
That should be the only standard we care about.

936
00:50:12,840 --> 00:50:16,640
It isn't about control for its own sake or performing process theatre to make leadership

937
00:50:16,640 --> 00:50:17,640
feel better.

938
00:50:17,640 --> 00:50:21,440
It certainly shouldn't be a central IT team protecting a platform from the very business

939
00:50:21,440 --> 00:50:22,680
it's supposed to serve.

940
00:50:22,680 --> 00:50:26,000
Instead governance should give the business the room it needs to build while ensuring

941
00:50:26,000 --> 00:50:30,920
those solutions don't quietly increase risk, duplicate effort, or break trust six months

942
00:50:30,920 --> 00:50:32,320
down the line.

943
00:50:32,320 --> 00:50:38,160
Leaders need to stop framing this as a choice between total central control and absolute chaos.

944
00:50:38,160 --> 00:50:41,440
That is a false choice that ignores how work actually happens.

945
00:50:41,440 --> 00:50:45,080
We already know what chaos looks like because we've spent this entire episode dissecting

946
00:50:45,080 --> 00:50:46,080
it.

947
00:50:46,080 --> 00:50:49,720
It looks like critical processes living in spreadsheets, work being rooted through personal

948
00:50:49,720 --> 00:50:54,320
inboxes and a few exhausted people holding the company together through sheer memory.

949
00:50:54,320 --> 00:50:58,520
But total central control isn't the answer either because when every minor change request

950
00:50:58,520 --> 00:51:02,920
enters the same massive queue, the work simply moves back into the shadows in the form of

951
00:51:02,920 --> 00:51:04,440
a workaround.

952
00:51:04,440 --> 00:51:08,760
What actually works is treating governance as a way to define lanes for the business.

953
00:51:08,760 --> 00:51:13,360
It's about being clear on who can build, where they can build, and what specific data they

954
00:51:13,360 --> 00:51:14,360
are allowed to touch.

955
00:51:14,360 --> 00:51:18,200
You define which connectors are safe, what moves freely through the system and exactly what

956
00:51:18,200 --> 00:51:19,880
requires a formal review.

957
00:51:19,880 --> 00:51:24,400
By defining what counts as low risk versus what crosses into enterprise level risk, you aren't

958
00:51:24,400 --> 00:51:25,720
creating a restriction.

959
00:51:25,720 --> 00:51:29,200
You are providing the clarity that reduces fear for everyone involved.

960
00:51:29,200 --> 00:51:32,400
When you have that clarity, business teams stop guessing whether they are allowed to

961
00:51:32,400 --> 00:51:33,600
solve their own problems.

962
00:51:33,600 --> 00:51:38,400
IT stops worrying that every local improvement will eventually become an untract liability that

963
00:51:38,400 --> 00:51:40,200
they have to fix later.

964
00:51:40,200 --> 00:51:44,800
Security stops discovering critical data exposures after the damage is already done, and support

965
00:51:44,800 --> 00:51:48,760
teams stop inheriting often solutions that no one can explain.

966
00:51:48,760 --> 00:51:51,200
Now map that logic to a company like Contoso.

967
00:51:51,200 --> 00:51:55,040
If the procurement team wants to improve a low risk intake process, the governance model

968
00:51:55,040 --> 00:51:56,760
should immediately show them their lane.

969
00:51:56,760 --> 00:52:01,200
It tells them to use a specific environment, stick to approved data sources, and follow

970
00:52:01,200 --> 00:52:03,560
a naming standard so the solution is searchable.

971
00:52:03,560 --> 00:52:07,640
It also gives them a clear escalation path if that process ever starts touching finance

972
00:52:07,640 --> 00:52:09,120
policy or regulated data.

973
00:52:09,120 --> 00:52:13,280
That is a much healthier model than making a team wait six months for a developer or forcing

974
00:52:13,280 --> 00:52:15,880
them to build in private and hope nobody notices.

975
00:52:15,880 --> 00:52:18,520
There is another reason this matters that people often miss.

976
00:52:18,520 --> 00:52:21,280
Good governance protects the builders, not just the platform.

977
00:52:21,280 --> 00:52:25,280
When a business team creates an automation without standards or lifecycle rules, the risk

978
00:52:25,280 --> 00:52:26,840
doesn't just sit with the company.

979
00:52:26,840 --> 00:52:29,080
It sits squarely on the person who built it.

980
00:52:29,080 --> 00:52:32,800
That person becomes the accidental owner, the accidental support desk, and the accidental

981
00:52:32,800 --> 00:52:34,480
risk carrier for that tool.

982
00:52:34,480 --> 00:52:38,800
Then when something inevitably breaks, the organization acts surprised that a bit of local initiative

983
00:52:38,800 --> 00:52:41,320
turned into a massive local liability.

984
00:52:41,320 --> 00:52:44,760
Governance prevents that by setting a professional boundary, it tells your people that if they

985
00:52:44,760 --> 00:52:49,240
build within these specific patterns, the solution can survive and thrive even after they

986
00:52:49,240 --> 00:52:50,760
move to a different role.

987
00:52:50,760 --> 00:52:53,960
This is structural compensation working in the right direction.

988
00:52:53,960 --> 00:52:57,560
Instead of people constantly compensating for a weak architecture, the architecture starts

989
00:52:57,560 --> 00:53:02,200
compensating for normal human limits like people going on leave or priorities shifting.

990
00:53:02,200 --> 00:53:06,160
Good governance assumes these changes will happen and builds a safer path before the pressure

991
00:53:06,160 --> 00:53:07,160
arrives.

992
00:53:07,160 --> 00:53:11,240
This is why I believe mature governance actually increases speed over the long term.

993
00:53:11,240 --> 00:53:14,800
It won't be faster than a single reckless shortcut in the first hour, but shortcuts are

994
00:53:14,800 --> 00:53:15,800
always a trap.

995
00:53:15,800 --> 00:53:20,240
At the level that actually matters to a business, repeated delivery across dozens of teams, governance

996
00:53:20,240 --> 00:53:21,960
removes the hesitation and the cleanup.

997
00:53:21,960 --> 00:53:25,880
It gives builders a known path and gives leaders a way to scale confidence instead of scaling

998
00:53:25,880 --> 00:53:26,880
anxiety.

999
00:53:26,880 --> 00:53:30,400
If your company still treats governance as the no team, I would challenge that perspective

1000
00:53:30,400 --> 00:53:31,400
directly.

1001
00:53:31,400 --> 00:53:35,080
Governance should be the very thing that lets more of your people build safely.

1002
00:53:35,080 --> 00:53:37,440
Why zone governance is the right stance now?

1003
00:53:37,440 --> 00:53:41,280
If we accept that governance is a guardrail rather than a break, we have to ask what kind

1004
00:53:41,280 --> 00:53:43,720
of model actually fits the modern workplace.

1005
00:53:43,720 --> 00:53:45,080
My answer is zone governance.

1006
00:53:45,080 --> 00:53:49,680
We have to move away from the idea of one rule for everything or open access for everyone.

1007
00:53:49,680 --> 00:53:53,440
This matters now more than ever because most organizations are currently living in two

1008
00:53:53,440 --> 00:53:55,280
different realities at the same time.

1009
00:53:55,280 --> 00:53:59,000
On paper, they talk as if every digital delivery is centrally controlled.

1010
00:53:59,000 --> 00:54:03,160
But in practice, the business is already building, automating and using AI to generate logic

1011
00:54:03,160 --> 00:54:05,960
faster than any old review model can handle.

1012
00:54:05,960 --> 00:54:09,440
That gap between policy and realities is exactly where bad architecture spreads like a

1013
00:54:09,440 --> 00:54:10,440
virus.

1014
00:54:10,440 --> 00:54:14,920
A zone model accepts a truth that central control models keep trying to resist.

1015
00:54:14,920 --> 00:54:17,480
Not every solution carries the same level of risk.

1016
00:54:17,480 --> 00:54:21,440
A departmental request tracker is simply not the same thing as an enterprise approval process

1017
00:54:21,440 --> 00:54:22,880
that touches finance controls.

1018
00:54:22,880 --> 00:54:26,800
If we govern a simple notification flow with the same weight as an app handling regulated

1019
00:54:26,800 --> 00:54:28,920
data, we either slow, low risk

1020
00:54:28,920 --> 00:54:32,120
work to a crawl or we under govern the high risk stuff.

1021
00:54:32,120 --> 00:54:34,440
Both of those options are failures of leadership.

1022
00:54:34,440 --> 00:54:39,560
The better stance is to define your lanes based on risk, visibility and business impact.

1023
00:54:39,560 --> 00:54:43,560
A green zone gives business teams the room they need to experiment inside safe boundaries

1024
00:54:43,560 --> 00:54:45,640
with approved connectors and clear ownership.

1025
00:54:45,640 --> 00:54:50,880
The goal here isn't to remove control, but to place that control at the boundary rather

1026
00:54:50,880 --> 00:54:52,640
than inside every tiny decision.

1027
00:54:52,640 --> 00:54:57,000
As a solution starts to touch sensitive data or a wider audience, the governance expectations

1028
00:54:57,000 --> 00:54:58,120
naturally increase.

1029
00:54:58,120 --> 00:55:03,400
You add more review and more involvement from security because the blast radius of a failure

1030
00:55:03,400 --> 00:55:04,640
is much larger.

1031
00:55:04,640 --> 00:55:07,440
That isn't red tape, it's just good operating design.

1032
00:55:07,440 --> 00:55:09,280
Think about how this looks at Contoso.

1033
00:55:09,280 --> 00:55:13,880
A local team, improving their own intake process, shouldn't have to wait behind the same

1034
00:55:13,880 --> 00:55:17,600
gate as a company-wide procurement system tied to audit thresholds.

1035
00:55:17,600 --> 00:55:21,520
At the same time, that procurement system shouldn't live in the same loose lane as a personal

1036
00:55:21,520 --> 00:55:22,840
productivity app.

1037
00:55:22,840 --> 00:55:27,160
Zoned governance gives each of those solutions a path that actually fits its purpose.

1038
00:55:27,160 --> 00:55:31,280
I call this structured autonomy because autonomy without zones eventually becomes sprawl

1039
00:55:31,280 --> 00:55:33,880
and control without zones always becomes a backlog.

1040
00:55:33,880 --> 00:55:37,400
This is especially critical right now because AI has fundamentally changed the speed of

1041
00:55:37,400 --> 00:55:38,400
creation.

1042
00:55:38,400 --> 00:55:42,320
Tools like co-pilot and agentec features have drastically reduced the effort required to

1043
00:55:42,320 --> 00:55:44,280
generate complex flows and apps.

1044
00:55:44,280 --> 00:55:48,160
While that is exciting, it also means that weak design choices can now scale faster than

1045
00:55:48,160 --> 00:55:49,160
ever before.

1046
00:55:49,160 --> 00:55:53,080
A bad approval path built slowly is a headache, but a bad approval path generated in seconds

1047
00:55:53,080 --> 00:55:55,800
and copied across the entire company is a catastrophe.

1048
00:55:55,800 --> 00:56:00,920
In an AI-shaped environment, Zoned governance stops being a nice-to-have maturity step and

1049
00:56:00,920 --> 00:56:02,120
becomes basic hygiene.

1050
00:56:02,120 --> 00:56:06,640
The business needs places where experimentation is safe and IT needs visibility into where that

1051
00:56:06,640 --> 00:56:10,360
experimentation ends and enterprise responsibility begins.

1052
00:56:10,360 --> 00:56:14,200
Security needs risk boundaries that reflect how people actually use the tools, not just

1053
00:56:14,200 --> 00:56:16,880
what is written in an idealized policy document.

1054
00:56:16,880 --> 00:56:21,160
Most importantly, builders need to know they can solve a problem without accidentally turning

1055
00:56:21,160 --> 00:56:24,440
themselves into an unplanned support desk for the next two years.

1056
00:56:24,440 --> 00:56:28,240
Zoned governance fits this moment because it reflects the reality of how we work.

1057
00:56:28,240 --> 00:56:32,080
It assumes people will build, it accepts that not every project needs a full architectural

1058
00:56:32,080 --> 00:56:36,560
review and it creates a way to scale without forcing every single problem into one giant

1059
00:56:36,560 --> 00:56:37,800
queue.

1060
00:56:37,800 --> 00:56:42,320
But once you see this clearly, you realize one thing, a model like this does not run itself.

1061
00:56:42,320 --> 00:56:46,320
Someone has to define those zones and watch the platform as it grows, which is exactly

1062
00:56:46,320 --> 00:56:50,720
where a center of excellence stops being an option and starts being a requirement.

1063
00:56:50,720 --> 00:56:53,240
What a power platform center of excellence actually does.

1064
00:56:53,240 --> 00:56:56,840
Once we accept that zone governance is the only logical stance we have to avoid the next

1065
00:56:56,840 --> 00:57:01,720
common mistake, which is imagining the center of excellence as a distant control tower,

1066
00:57:01,720 --> 00:57:04,880
sitting inside IT and issuing rules to everyone else.

1067
00:57:04,880 --> 00:57:08,600
That model looks clean on an organizational chart, but it almost always fails in a real

1068
00:57:08,600 --> 00:57:12,600
company because it creates a disconnect between the people making the rules and the people

1069
00:57:12,600 --> 00:57:13,680
doing the work.

1070
00:57:13,680 --> 00:57:17,840
A power platform center of excellence only works when it behaves less like a gatekeeper

1071
00:57:17,840 --> 00:57:22,400
and more like a cross-functional operating function that connects platform management,

1072
00:57:22,400 --> 00:57:25,560
business demand and security needs in one place.

1073
00:57:25,560 --> 00:57:30,000
Otherwise it just becomes another queue or another layer of review that people will inevitably

1074
00:57:30,000 --> 00:57:33,000
route around as soon as the pressure to deliver rises.

1075
00:57:33,000 --> 00:57:36,040
And then we are right back where we started with a fragmented system.

1076
00:57:36,040 --> 00:57:39,040
So what does a functioning COE actually do in a business reality?

1077
00:57:39,040 --> 00:57:43,640
First, it manages the platform as shared infrastructure rather than a collection of individual

1078
00:57:43,640 --> 00:57:44,640
projects.

1079
00:57:44,640 --> 00:57:47,920
This means that environments, connector policies, access patterns and monitoring are handled

1080
00:57:47,920 --> 00:57:50,600
with intent instead of being left to drift over time.

1081
00:57:50,600 --> 00:57:54,560
The goal here isn't to centralize every single build, but rather to ensure the ground people

1082
00:57:54,560 --> 00:57:58,840
are building on stays stable and governable as adoption grows across the company.

1083
00:57:58,840 --> 00:58:03,120
Second, it defines policy in a way that builders can actually use in their daily work.

1084
00:58:03,120 --> 00:58:07,480
We aren't talking about 50-page PDF documents that no one reads, but rather clear lanes and

1085
00:58:07,480 --> 00:58:09,840
data rules that answer practical questions.

1086
00:58:09,840 --> 00:58:13,400
A maker needs to know if they can build in a team environment which connectors are safe

1087
00:58:13,400 --> 00:58:17,080
to use and who owns the app after they move to a different role.

1088
00:58:17,080 --> 00:58:21,400
What governance translates high-level risk into operating decisions that people can follow

1089
00:58:21,400 --> 00:58:24,560
without needing to schedule a meeting every time they want to start a flow?

1090
00:58:24,560 --> 00:58:28,760
Third, the COE enables people, which is a part of the system that matters more than many

1091
00:58:28,760 --> 00:58:29,760
leaders expect.

1092
00:58:29,760 --> 00:58:32,240
The COE isn't just there to prevent bad outcomes.

1093
00:58:32,240 --> 00:58:35,920
It exists to increase the number of people who can build safely by providing training,

1094
00:58:35,920 --> 00:58:37,640
office hours and templates.

1095
00:58:37,640 --> 00:58:41,960
If every team has to figure out naming standards and support models from scratch, the platform

1096
00:58:41,960 --> 00:58:44,400
will fragment quickly, even if everyone has good intentions.

1097
00:58:44,400 --> 00:58:48,640
By providing reusable patterns and approved templates for common apps, the COE reduces

1098
00:58:48,640 --> 00:58:52,200
both hesitation and the constant reinvention of the wheel.

1099
00:58:52,200 --> 00:58:55,680
These things might sound like small details until you try to operate without them, and

1100
00:58:55,680 --> 00:58:59,400
then every build becomes a custom negotiation that simply does not scale.

1101
00:58:59,400 --> 00:59:04,200
Fourth, it creates visibility so the organization can shift the conversation from rumours to actual

1102
00:59:04,200 --> 00:59:07,600
evidence instead of asking around to find out who built what.

1103
00:59:07,600 --> 00:59:12,080
The COE uses inventories and usage analytics to understand exactly what is happening on

1104
00:59:12,080 --> 00:59:13,080
the platform.

1105
00:59:13,080 --> 00:59:17,440
It matters because invisible growth is where trust starts to erode, whereas visible growth

1106
00:59:17,440 --> 00:59:20,680
is something that leadership can actually shape and support.

1107
00:59:20,680 --> 00:59:24,280
Without this visibility, you are stuck governing retrospectively, which means you're always

1108
00:59:24,280 --> 00:59:28,680
cleaning up after risk appears or investigating after sprawl has already taken over.

1109
00:59:28,680 --> 00:59:33,400
Finally, the COE acts as the bridge between business speed and enterprise accountability.

1110
00:59:33,400 --> 00:59:37,760
The business needs to solve process problems quickly, but IT needs the platform to remain

1111
00:59:37,760 --> 00:59:42,960
supportable, and security needs clear risk boundaries. The COE sits in the middle of those competing

1112
00:59:42,960 --> 00:59:46,760
pressures and gives that tension a structure instead of pretending it doesn't exist.

1113
00:59:46,760 --> 00:59:50,640
When people ask me what a center of excellence actually does, I tell them it makes business-led

1114
00:59:50,640 --> 00:59:54,080
building visible, supportable, and safe enough to scale.

1115
00:59:54,080 --> 00:59:58,080
Without that specific function, zoned governance is just a slide in a deck, but with it, the

1116
00:59:58,080 --> 01:00:01,600
platform becomes a resilient operating model.

1117
01:00:01,600 --> 01:00:03,880
The business case for governed adoption.

1118
01:00:03,880 --> 01:00:07,800
Once the center of excellence enters the picture, leadership usually asks what this actually

1119
01:00:07,800 --> 01:00:10,840
changes in business terms rather than just platform language.

1120
01:00:10,840 --> 01:00:14,400
This is where the case for governance gets much stronger because governed adoption isn't

1121
01:00:14,400 --> 01:00:16,480
just a soft maturity idea.

1122
01:00:16,480 --> 01:00:21,600
It actually changes throughput and risk in ways that executives already care about.

1123
01:00:21,600 --> 01:00:26,480
Organizations with mature centers of excellence report 67% faster solution delivery and 72%

1124
01:00:26,480 --> 01:00:31,520
better security posture, which proves that you can be faster and safer at the same time.

1125
01:00:31,520 --> 01:00:35,480
Many leadership teams still assume that governance slows things down, but in practice it is poor

1126
01:00:35,480 --> 01:00:40,000
governance that creates the drag through rework, cleanup, and late stage interventions.

1127
01:00:40,000 --> 01:00:43,280
Good governance removes that drag by creating a system where speed is sustainable.

1128
01:00:43,280 --> 01:00:46,680
Speed in a company isn't just about building one thing quickly, it is about building a thousand

1129
01:00:46,680 --> 01:00:49,840
things without constantly creating new layers of uncertainty.

1130
01:00:49,840 --> 01:00:53,760
If every automation has to be rediscovered or rescued later, you aren't actually moving

1131
01:00:53,760 --> 01:00:57,520
fast, you're just borrowing time from the future and calling it acceleration.

1132
01:00:57,520 --> 01:01:02,480
A mature COE changes that pattern by creating reusable lanes and support parts so that delivery

1133
01:01:02,480 --> 01:01:06,160
gets faster because fewer decisions have to be reinvented every single time.

1134
01:01:06,160 --> 01:01:09,640
The second part of the business case is reducing risk through enablement rather than through

1135
01:01:09,640 --> 01:01:11,160
fear or restriction.

1136
01:01:11,160 --> 01:01:15,840
Training and structured support can reduce security risk by 40% to 50% in mature models, which

1137
01:01:15,840 --> 01:01:18,800
points to a truth that many leaders often miss.

1138
01:01:18,800 --> 01:01:22,360
Risk doesn't rise just because people are building things, it rises when they build without

1139
01:01:22,360 --> 01:01:25,600
context review paths or clarity on where the boundaries are.

1140
01:01:25,600 --> 01:01:30,120
Once you give those same builders approved patterns and visible environments, that decentralized

1141
01:01:30,120 --> 01:01:33,080
energy becomes a productive asset instead of a liability.

1142
01:01:33,080 --> 01:01:37,240
Now, compare that to the unguided version where environments face three to four times higher

1143
01:01:37,240 --> 01:01:39,400
rates of sprawl and security violations.

1144
01:01:39,400 --> 01:01:43,400
That isn't just a small penalty, it is a structural warning that the platform will eventually

1145
01:01:43,400 --> 01:01:45,400
fail to meet executive expectations.

1146
01:01:45,400 --> 01:01:49,080
The question is never whether people can build useful solutions because they obviously can,

1147
01:01:49,080 --> 01:01:52,920
but whether those solutions stay defensible once adoption spreads across every department.

1148
01:01:52,920 --> 01:01:56,760
Without governance, the answer eventually drifts toward no, and once that happens executive

1149
01:01:56,760 --> 01:01:59,680
confidence drops and funding for the platform begins to dry up.

1150
01:01:59,680 --> 01:02:03,320
If we map this back to a company like Contoso, we can see how the system would play out

1151
01:02:03,320 --> 01:02:04,320
over time.

1152
01:02:04,320 --> 01:02:08,560
Without a COE procurement might improve one workflow while finance automates another and

1153
01:02:08,560 --> 01:02:10,680
for a few months that looks like real progress.

1154
01:02:10,680 --> 01:02:14,840
However, the same old patterns eventually return in a new shape leading to duplicate flows,

1155
01:02:14,840 --> 01:02:18,840
unclear ownership and hidden dependencies that cause the architecture to fragment.

1156
01:02:18,840 --> 01:02:22,720
But with governed adoption, those improvements start compounding because one approval pattern

1157
01:02:22,720 --> 01:02:26,480
informs the next and one environment model supports the next team.

1158
01:02:26,480 --> 01:02:30,880
That is what executives should really be buying when they invest in the power platform.

1159
01:02:30,880 --> 01:02:34,800
They aren't just buying apps or flows, they are buying a repeatable way to increase delivery

1160
01:02:34,800 --> 01:02:38,520
capacity without multiplying their hidden technical risk.

1161
01:02:38,520 --> 01:02:41,800
If I were sitting at the leadership table, I would tell them plainly that governance is

1162
01:02:41,800 --> 01:02:43,960
not a cost center attached to low code.

1163
01:02:43,960 --> 01:02:48,040
It is the fundamental condition that makes low code trustworthy enough to scale across

1164
01:02:48,040 --> 01:02:49,440
the entire enterprise.

1165
01:02:49,440 --> 01:02:53,120
Once the platform is trustworthy, the business stops treating every solution like a one-off

1166
01:02:53,120 --> 01:02:57,080
experiment and starts treating governed delivery as a core part of their normal operating

1167
01:02:57,080 --> 01:02:58,800
capability.

1168
01:02:58,800 --> 01:03:03,080
The economics, from hidden labour to measurable return, once leadership starts viewing

1169
01:03:03,080 --> 01:03:07,520
governance as a way to protect throughput, the financial questions always follow closely

1170
01:03:07,520 --> 01:03:08,520
behind.

1171
01:03:08,520 --> 01:03:12,320
Executives want to know what these costs and what the return looks like, which is a fair

1172
01:03:12,320 --> 01:03:16,240
question, but it usually enters the room attached to a very misleading comparison.

1173
01:03:16,240 --> 01:03:20,080
The sell looks cheap because the license is already paid for, the files are familiar and

1174
01:03:20,080 --> 01:03:24,080
email is already running, so nobody has to request a new platform budget just to keep

1175
01:03:24,080 --> 01:03:26,080
a shadow system alive.

1176
01:03:26,080 --> 01:03:30,000
Because of that, the organization mistake, the visible cost for the full cost, it isn't.

1177
01:03:30,000 --> 01:03:34,000
The spreadsheet itself is cheap, but the operating model required to keep that spreadsheet

1178
01:03:34,000 --> 01:03:36,120
functioning is incredibly expensive.

1179
01:03:36,120 --> 01:03:37,600
That is the distinction we have to make.

1180
01:03:37,600 --> 01:03:42,200
When a procurement cycle takes nine days instead of two, someone is paying for that delay,

1181
01:03:42,200 --> 01:03:46,520
and when rework climbs above 20%, the business is paying for that repetition.

1182
01:03:46,520 --> 01:03:50,960
Whether it's finance, reconciling, inconsistent versions, or managers chasing status updates

1183
01:03:50,960 --> 01:03:55,560
manually, that labour is real even if it never shows up on a software invoice.

1184
01:03:55,560 --> 01:03:59,920
The business has simply pushed the process cost into people's time and management's attention.

1185
01:03:59,920 --> 01:04:02,840
This is exactly why file-based logic survives as long as it does.

1186
01:04:02,840 --> 01:04:06,560
Its waste is distributed across the company, so no single line item looks dramatic enough

1187
01:04:06,560 --> 01:04:10,160
to trigger an alarm, yet the total drag on the system remains.

1188
01:04:10,160 --> 01:04:14,320
Because this drag sits inside ordinary work, companies eventually normalise it and call

1189
01:04:14,320 --> 01:04:17,040
it coordination, or just how things work here.

1190
01:04:17,040 --> 01:04:21,400
If you look at it structurally, this is just hidden labour being used to keep a weak architecture

1191
01:04:21,400 --> 01:04:22,560
on life support.

1192
01:04:22,560 --> 01:04:24,640
Now compare that to the power platform.

1193
01:04:24,640 --> 01:04:29,520
Tools like Power Automate and Power Apps introduce an explicit cost through premium licensing,

1194
01:04:29,520 --> 01:04:32,560
implementation effort, and the need for a centre of excellence.

1195
01:04:32,560 --> 01:04:37,280
This spend is much easier to see, which naturally makes executives more skeptical, but that

1196
01:04:37,280 --> 01:04:40,560
visibility is actually a massive advantage for the business case.

1197
01:04:40,560 --> 01:04:44,560
The organization is finally converting hidden, unmanaged waste into a measurable investment

1198
01:04:44,560 --> 01:04:46,160
that can actually be optimised.

1199
01:04:46,160 --> 01:04:49,960
A hidden cost never gets improved because nobody owns it, but a visible platform cost

1200
01:04:49,960 --> 01:04:53,400
forces you to ask if you're getting a return on the architecture you're funding.

1201
01:04:53,400 --> 01:04:56,120
In most cases, the answer is a resounding yes.

1202
01:04:56,120 --> 01:05:01,520
Research on Power Platform scenarios shows a 206% ROI over three years, with the system

1203
01:05:01,520 --> 01:05:03,920
often paying for itself in about six months.

1204
01:05:03,920 --> 01:05:08,920
High-impact users can save up to 250 hours a year, and even if your company lands below

1205
01:05:08,920 --> 01:05:11,000
those top numbers, the direction is clear.

1206
01:05:11,000 --> 01:05:15,240
Once you move manual routing and status chasing into a governed flow, you open a real labour

1207
01:05:15,240 --> 01:05:16,240
capacity.

1208
01:05:16,240 --> 01:05:18,760
I won't lead us to hear this clearly, this isn't about reducing headcount.

1209
01:05:18,760 --> 01:05:22,960
It is about stopping the company from burning its most skilled people on low-trust coordination

1210
01:05:22,960 --> 01:05:23,960
tasks.

1211
01:05:23,960 --> 01:05:28,120
If your finance analysts spend hours every week manually reconciling spreadsheets, or if

1212
01:05:28,120 --> 01:05:32,840
operations managers are stuck chasing approvals, that is a direct loss of system capacity.

1213
01:05:32,840 --> 01:05:36,960
The return on governed architecture comes from restoring that capacity, so people can

1214
01:05:36,960 --> 01:05:39,640
focus on work that actually moves the business forward.

1215
01:05:39,640 --> 01:05:41,160
Look at the Contoso example again.

1216
01:05:41,160 --> 01:05:45,400
Before the redesign, procurement looked cheap because the file was free, but the process

1217
01:05:45,400 --> 01:05:49,160
was bleeding money through elapsed time and investigation effort.

1218
01:05:49,160 --> 01:05:53,280
After the redesign, the process carried a platform cost, but it bought back flow, trust, and

1219
01:05:53,280 --> 01:05:54,440
management bandwidth.

1220
01:05:54,440 --> 01:05:58,440
That is a completely different economic story than simply replacing Excel with a more

1221
01:05:58,440 --> 01:05:59,760
expensive tool.

1222
01:05:59,760 --> 01:06:03,560
The better framing is that Excel hides operational waste inside the salary lines you've already

1223
01:06:03,560 --> 01:06:07,840
approved, while a governed power platform makes that investment visible enough to manage.

1224
01:06:07,840 --> 01:06:11,880
Cheap tools that drive expensive behaviour are not actually cheap, and governed platforms

1225
01:06:11,880 --> 01:06:14,400
with measurable returns are not actually expensive.

1226
01:06:14,400 --> 01:06:15,560
They are accountable.

1227
01:06:15,560 --> 01:06:19,880
In a business under pressure to move faster without adding more overhead, accountable architecture

1228
01:06:19,880 --> 01:06:22,000
is always the better deal.

1229
01:06:22,000 --> 01:06:24,280
Security and compliance the risk you already have.

1230
01:06:24,280 --> 01:06:27,800
This is usually the point where someone speaks up and says that the power platform increases

1231
01:06:27,800 --> 01:06:29,560
security and compliance risk.

1232
01:06:29,560 --> 01:06:33,040
I understand that reaction because a new platform with more builders and more connectors

1233
01:06:33,040 --> 01:06:36,640
sounds like you're introducing exposure the company didn't have before.

1234
01:06:36,640 --> 01:06:40,400
But from a system perspective, that framing is completely backwards because the exposure

1235
01:06:40,400 --> 01:06:41,400
is already there.

1236
01:06:41,400 --> 01:06:45,280
The only difference is that right now in your Excel shadow systems that exposure sits in

1237
01:06:45,280 --> 01:06:48,120
places the company cannot see or govern.

1238
01:06:48,120 --> 01:06:53,040
Files move through email, attachments get downloaded to local drives, and access depends

1239
01:06:53,040 --> 01:06:55,360
entirely on who forwarded what to whom.

1240
01:06:55,360 --> 01:06:59,320
An approval evidence is scattered between a spreadsheet, a mailbox and someone's personal

1241
01:06:59,320 --> 01:07:00,320
memory.

1242
01:07:00,320 --> 01:07:04,600
You have a system with three different storage models for one single process.

1243
01:07:04,600 --> 01:07:07,880
When leaders tell me they're worried about the risk of a new platform, I think we need

1244
01:07:07,880 --> 01:07:11,560
to translate the current state of their safe spreadsheets honestly.

1245
01:07:11,560 --> 01:07:16,040
You have no clean audit trail, weak access logic, uncontrolled file sharing, and manual

1246
01:07:16,040 --> 01:07:18,000
workarounds for every official process.

1247
01:07:18,000 --> 01:07:22,200
That isn't a low risk environment, it is unmanaged risk with a familiar brand name,

1248
01:07:22,200 --> 01:07:24,560
and we often mistake familiarity for safety.

1249
01:07:24,560 --> 01:07:29,240
Moving back to the contoso procurement process before we fixed it, requests arrived as attachments,

1250
01:07:29,240 --> 01:07:33,720
approvals happened in long email threads and clarifications were buried in hallway conversations.

1251
01:07:33,720 --> 01:07:37,640
Different people held different copies of the same request, meaning finance might be reviewing

1252
01:07:37,640 --> 01:07:40,240
one version while procurement looked at another.

1253
01:07:40,240 --> 01:07:44,200
If an auditor asks for a reliable sequence of events, the company has to reconstruct the

1254
01:07:44,200 --> 01:07:48,480
answer after the fact, but reconstruction is not control its compensation.

1255
01:07:48,480 --> 01:07:52,680
This matters even more as we head into 2026 because file-based workflows are getting

1256
01:07:52,680 --> 01:07:56,560
hit by operational fragility and security exposure at the same time.

1257
01:07:56,560 --> 01:08:00,640
Research into Excel automation shows growing weaknesses in unmanaged file logic, ranging

1258
01:08:00,640 --> 01:08:05,280
from macro threats to new attack paths inside office environments, even without a dramatic

1259
01:08:05,280 --> 01:08:09,440
threat model, if a critical process depends on scattered files and weak traceability your

1260
01:08:09,440 --> 01:08:12,200
security is already below the level you think it is.

1261
01:08:12,200 --> 01:08:15,000
The risk doesn't start when the power platform enters the room.

1262
01:08:15,000 --> 01:08:18,400
The risk simply becomes visible when governed architecture arrives.

1263
01:08:18,400 --> 01:08:21,760
Govern systems don't remove the need for security discipline, but they do raise the standard

1264
01:08:21,760 --> 01:08:24,920
by providing logging, policy enforcement and environment controls.

1265
01:08:24,920 --> 01:08:30,320
You finally get a place to define which connectors are acceptable and which data can move where,

1266
01:08:30,320 --> 01:08:33,960
shifting the conversation from vague concern to intentional design.

1267
01:08:33,960 --> 01:08:38,560
Instead of asking if something might be risky, the company can finally ask who has access,

1268
01:08:38,560 --> 01:08:41,480
what data it touches and where the audit record lives.

1269
01:08:41,480 --> 01:08:45,480
Matur organizations lower their risk by refusing to tolerate invisible architecture.

1270
01:08:45,480 --> 01:08:49,960
There is a real irony in companies rejecting governed platforms in the name of compliance

1271
01:08:49,960 --> 01:08:54,200
while they continue to run billion dollar processes through email attachments.

1272
01:08:54,200 --> 01:08:58,560
From a system perspective that isn't cautioned, it's a misclassification of reality.

1273
01:08:58,560 --> 01:09:02,400
They are labeling the visible platform as risky while treating the invisible unmanaged

1274
01:09:02,400 --> 01:09:03,560
workaround as normal.

1275
01:09:03,560 --> 01:09:07,960
But that invisible workaround is already your breach surface, your audit weakness and your

1276
01:09:07,960 --> 01:09:09,120
retention problem.

1277
01:09:09,120 --> 01:09:11,080
The executive stance should be simple.

1278
01:09:11,080 --> 01:09:15,680
Don't compare a governed platform to an imagined secure version of the present, compared

1279
01:09:15,680 --> 01:09:18,400
to the actual messy process you have running right now.

1280
01:09:18,400 --> 01:09:20,960
If you do that, honestly the conclusion changes fast.

1281
01:09:20,960 --> 01:09:25,160
The question isn't whether the power platform introduces risk, but whether it gives you the

1282
01:09:25,160 --> 01:09:28,400
first real chance to govern the risk you're already carrying.

1283
01:09:28,400 --> 01:09:31,600
Why identity and access matter more than most teams think?

1284
01:09:31,600 --> 01:09:35,280
One security enters the conversation, identity becomes the next layer that most teams

1285
01:09:35,280 --> 01:09:36,440
still underestimate.

1286
01:09:36,440 --> 01:09:40,200
A governed process is not just about where the logic runs, but it is also about who can

1287
01:09:40,200 --> 01:09:44,760
trigger it, who can see the data and who keeps access when their job description changes.

1288
01:09:44,760 --> 01:09:48,640
If those decisions stay loose, automation will expand your reach much faster than your

1289
01:09:48,640 --> 01:09:50,080
accountability can keep up.

1290
01:09:50,080 --> 01:09:54,040
The workflow might look cleaner on the surface, but the control model underneath it remains

1291
01:09:54,040 --> 01:09:55,040
dangerously weak.

1292
01:09:55,040 --> 01:09:59,080
This is where Microsoft Enter ID matters far more than many business teams realize.

1293
01:09:59,080 --> 01:10:03,760
A lot of organizations still treat identity as background infrastructure like a login or

1294
01:10:03,760 --> 01:10:08,480
a password, but when you start building real-process architecture on power platform identity stops

1295
01:10:08,480 --> 01:10:10,080
being background noise.

1296
01:10:10,080 --> 01:10:14,240
It becomes the access backbone for your entire operating model, where role-based access

1297
01:10:14,240 --> 01:10:18,760
and lifecycle control determine whether the process reflects business reality or quietly

1298
01:10:18,760 --> 01:10:20,120
drifts away from it.

1299
01:10:20,120 --> 01:10:22,440
Now map that to the situation at Contoso.

1300
01:10:22,440 --> 01:10:27,480
In the old Excel pattern, access depended entirely on distribution, meaning if you had the

1301
01:10:27,480 --> 01:10:31,760
file or the mail thread you often had more visibility than you actually should.

1302
01:10:31,760 --> 01:10:36,320
If someone forwarded a spreadsheet to help move the work along, access expanded informally

1303
01:10:36,320 --> 01:10:37,600
without any oversight.

1304
01:10:37,600 --> 01:10:41,520
If a manager changed roles but stayed on an old email thread, they still carried context

1305
01:10:41,520 --> 01:10:45,680
they no longer needed and the process simply inherited the looseness of email behavior.

1306
01:10:45,680 --> 01:10:48,120
That is not access control, that is access residue.

1307
01:10:48,120 --> 01:10:52,680
In a governed model, identity changes the fundamental question from who has the file to who

1308
01:10:52,680 --> 01:10:55,960
should have access based on their role and current responsibility.

1309
01:10:55,960 --> 01:10:59,720
While that sounds obvious, it changes everything because a requester can track their own item

1310
01:10:59,720 --> 01:11:04,600
without seeing unrelated requests and a manager can approve items strictly within their span

1311
01:11:04,600 --> 01:11:06,120
of control.

1312
01:11:06,120 --> 01:11:10,640
Finance can review cases based on specific thresholds while procurement administers the workflow

1313
01:11:10,640 --> 01:11:15,160
and platform admins can support the environment without gaining casual access to business data

1314
01:11:15,160 --> 01:11:16,160
they do not need.

1315
01:11:16,160 --> 01:11:20,680
That is a stronger model because access finally starts reflecting operating reality.

1316
01:11:20,680 --> 01:11:23,600
And why does that matter more as we head into 2026?

1317
01:11:23,600 --> 01:11:27,760
Modern authentication and MFA enforcement are becoming less optional across the Microsoft

1318
01:11:27,760 --> 01:11:31,120
estate as legacy authentication is phased out.

1319
01:11:31,120 --> 01:11:34,880
Security defaults and stronger sign in controls are becoming the normal expectation rather

1320
01:11:34,880 --> 01:11:36,640
than a sign of advanced maturity.

1321
01:11:36,640 --> 01:11:40,640
So if a company keeps building logic on top of inherited access habits, the friction will

1322
01:11:40,640 --> 01:11:41,840
only grow.

1323
01:11:41,840 --> 01:11:46,560
This is not because Microsoft is being difficult but because the old trust model no longer matches

1324
01:11:46,560 --> 01:11:48,280
the risk surface of modern work.

1325
01:11:48,280 --> 01:11:49,760
This matters even more.

1326
01:11:49,760 --> 01:11:53,000
Once automation starts acting across your different systems.

1327
01:11:53,000 --> 01:11:56,960
A flow can send approvals and update records in the background but if the identity model

1328
01:11:56,960 --> 01:12:01,080
under that automation is vague, the blast radius grows quietly, people can end up with

1329
01:12:01,080 --> 01:12:03,280
access that outlives their role.

1330
01:12:03,280 --> 01:12:06,760
And service connections can become invisible dependencies that nobody is tracking.

1331
01:12:06,760 --> 01:12:11,280
When something fails or exposes data, the business discovers too late that it automated the

1332
01:12:11,280 --> 01:12:14,880
movement of information without automating the accountability behind it.

1333
01:12:14,880 --> 01:12:19,120
From a system perspective, weak identity turns automation into unmanaged reach while strong

1334
01:12:19,120 --> 01:12:21,440
identity turns it into governed execution.

1335
01:12:21,440 --> 01:12:22,440
That is the distinction.

1336
01:12:22,440 --> 01:12:27,000
When I look at power platform architecture, I do not see entry ID as a technical add-on,

1337
01:12:27,000 --> 01:12:29,480
but rather as a vital part of the control plane.

1338
01:12:29,480 --> 01:12:34,080
It decides whether the process can enforce least necessary access and whether risky conditions

1339
01:12:34,080 --> 01:12:36,840
should trigger stronger controls when a user signs in.

1340
01:12:36,840 --> 01:12:41,480
It ensures that role changes actually reshape who can do what inside the flow which has

1341
01:12:41,480 --> 01:12:44,720
direct business implications for how you handle your data.

1342
01:12:44,720 --> 01:12:49,040
Audit readiness improves because access is tied to policy instead of habit and your security

1343
01:12:49,040 --> 01:12:53,840
posture gets stronger because approval rights are not floating around in old threads.

1344
01:12:53,840 --> 01:12:56,880
Operational resilience improves because when people move or leave the company, their

1345
01:12:56,880 --> 01:13:00,520
access moves with governance instead of staying behind as residue.

1346
01:13:00,520 --> 01:13:05,160
Once AI enters the platform, this requirement gets even sharper because agents and co-pilots

1347
01:13:05,160 --> 01:13:09,560
can act quickly, but they should never outrun the identity rules that define what they are

1348
01:13:09,560 --> 01:13:10,720
allowed to touch.

1349
01:13:10,720 --> 01:13:14,240
If your access is loose, AI will simply scale that loose access.

1350
01:13:14,240 --> 01:13:18,240
If your identity is governed, AI operates inside much clearer boundaries.

1351
01:13:18,240 --> 01:13:19,680
The business case is simple.

1352
01:13:19,680 --> 01:13:24,120
If your process architecture is going to become more automated and more intelligent, then identity

1353
01:13:24,120 --> 01:13:25,600
cannot stay an afterthought.

1354
01:13:25,600 --> 01:13:29,360
It has to become part of the design because without identity discipline, automation expands

1355
01:13:29,360 --> 01:13:33,840
faster than trust, and AI will only amplify that architectural weakness.

1356
01:13:33,840 --> 01:13:37,240
AI does not remove the need for architecture, it amplifies it.

1357
01:13:37,240 --> 01:13:41,200
Once AI enters the platform, a lot of leaders start assuming the hard part of the job is

1358
01:13:41,200 --> 01:13:42,200
over.

1359
01:13:42,200 --> 01:13:45,720
They see co-pilot generate an app draft or suggest a flow.

1360
01:13:45,720 --> 01:13:48,600
And they think the platform has suddenly become self-solving.

1361
01:13:48,600 --> 01:13:51,440
The assumption is understandable, but I think the opposite is true.

1362
01:13:51,440 --> 01:13:54,440
When creation gets easier, your architecture actually matters more.

1363
01:13:54,440 --> 01:13:59,040
AI reduces the effort required to produce logic, but it does not reduce the need for that

1364
01:13:59,040 --> 01:14:00,360
logic to be good.

1365
01:14:00,360 --> 01:14:03,780
It reduces the time between an idea and its implementation, but it does not reduce the

1366
01:14:03,780 --> 01:14:05,360
consequences of a weak design.

1367
01:14:05,360 --> 01:14:10,240
If anything, AI removes the friction that used to slow bad decisions down, which means

1368
01:14:10,240 --> 01:14:15,680
the business can now generate flawed workflows and unsafe data interactions much faster than

1369
01:14:15,680 --> 01:14:16,680
before.

1370
01:14:16,680 --> 01:14:20,640
That is why I keep coming back to the point that AI does not remove your design responsibility.

1371
01:14:20,640 --> 01:14:24,800
It simply compresses the distance between the quality of your design and the business impact

1372
01:14:24,800 --> 01:14:25,800
it creates.

1373
01:14:25,800 --> 01:14:27,920
Now map that back to the reality at Contoso.

1374
01:14:27,920 --> 01:14:31,440
In the old world, building a poor workaround still took some effort because someone had to

1375
01:14:31,440 --> 01:14:34,640
shape the spreadsheet and explain the steps to keep the file alive.

1376
01:14:34,640 --> 01:14:38,240
While that was fragile, it was at least slow enough to contain itself for a while, but in

1377
01:14:38,240 --> 01:14:43,080
an AI-assisted world, a manager can describe a need in plain language and get a version

1378
01:14:43,080 --> 01:14:44,800
1.0 immediately.

1379
01:14:44,800 --> 01:14:48,880
A team can spin up an agent that appears useful before anyone has asked the important

1380
01:14:48,880 --> 01:14:50,800
questions about ownership or life cycle.

1381
01:14:50,800 --> 01:14:53,600
The surface gets smoother, but the risk gets faster.

1382
01:14:53,600 --> 01:14:57,360
And why is that AI is an acceleration layer rather than a governance layer, so while it

1383
01:14:57,360 --> 01:15:01,280
helps people create, it does not automatically classify risk well enough for enterprise

1384
01:15:01,280 --> 01:15:02,280
use.

1385
01:15:02,280 --> 01:15:05,480
It does not reliably understand your internal control model, and it certainly does not

1386
01:15:05,480 --> 01:15:09,360
decide whether a process belongs in a protected green zone or a standard enterprise

1387
01:15:09,360 --> 01:15:10,360
lane.

1388
01:15:10,360 --> 01:15:14,200
It does not own the consequences when generated logic reaches production with weak assumptions

1389
01:15:14,200 --> 01:15:17,960
baked into it because that responsibility still belongs to us.

1390
01:15:17,960 --> 01:15:22,120
This often makes a very expensive mistake by confusing fluency with fit.

1391
01:15:22,120 --> 01:15:26,760
If an AI tool can build something that looks coherent, they assume it fits the operating

1392
01:15:26,760 --> 01:15:30,720
reality of the business, but process architecture is not just about producing something that

1393
01:15:30,720 --> 01:15:31,720
runs.

1394
01:15:31,720 --> 01:15:35,200
It is about producing something the company can trust and govern under pressure.

1395
01:15:35,200 --> 01:15:39,000
A generated approval flow may look neat, but that does not mean the escalation path is

1396
01:15:39,000 --> 01:15:43,360
right, and a co-pilot-built app may collect data cleanly without the data boundary being

1397
01:15:43,360 --> 01:15:44,360
correct.

1398
01:15:44,360 --> 01:15:49,520
In perspective, AI exposes weak architecture faster than manual methods ever could.

1399
01:15:49,520 --> 01:15:53,360
It reveals where your policies are vague and where your ownership is unclear.

1400
01:15:53,360 --> 01:15:57,760
Showing exactly where data structures were never stable enough to support automation safely.

1401
01:15:57,760 --> 01:16:02,160
This is why the 2026 direction inside Power Platform matters so much.

1402
01:16:02,160 --> 01:16:06,640
As the move toward agenteic governance and real-time risk assessment is a direct response to

1403
01:16:06,640 --> 01:16:09,880
a new condition where creation is outrunning old review models.

1404
01:16:09,880 --> 01:16:13,600
If the business can generate apps and agents faster than the organization can understand

1405
01:16:13,600 --> 01:16:16,840
them, then governance has to become more embedded and continuous.

1406
01:16:16,840 --> 01:16:19,720
It shouldn't be slower, but it definitely needs to be smarter.

1407
01:16:19,720 --> 01:16:22,280
For any leader listening, I would frame it this way.

1408
01:16:22,280 --> 01:16:25,840
If your architecture is weak, AI will not hide that weakness.

1409
01:16:25,840 --> 01:16:26,680
It will scale it.

1410
01:16:26,680 --> 01:16:30,920
If your boundaries are vague, AI will operate inside that vagueness at high speed.

1411
01:16:30,920 --> 01:16:35,640
If your ownership model is missing, AI will simply multiply your unsupported assets.

1412
01:16:35,640 --> 01:16:40,000
However, if your governance is mature, AI becomes a force multiplier for good patents

1413
01:16:40,000 --> 01:16:41,640
and clearer observability.

1414
01:16:41,640 --> 01:16:43,800
That is why this first episode has to land here.

1415
01:16:43,800 --> 01:16:48,440
Before we talk about AI ambition or prompt driven building, you have to focus on architecture

1416
01:16:48,440 --> 01:16:52,240
because the platform will now let you build faster than your instincts were trained to

1417
01:16:52,240 --> 01:16:53,240
govern.

1418
01:16:53,240 --> 01:16:57,200
If you do not fix that first, you will not get an intelligent operating model.

1419
01:16:57,200 --> 01:17:02,160
You will just get smarter shadow systems where to start without doing too much at once.

1420
01:17:02,160 --> 01:17:05,600
So after looking at the big picture, the practical question becomes very simple.

1421
01:17:05,600 --> 01:17:08,680
Where do you actually start without triggering another wave of chaos?

1422
01:17:08,680 --> 01:17:12,680
This is where many organizations overcorrect because they finally see the shadow system

1423
01:17:12,680 --> 01:17:15,840
problem and decide to launch a massive transformation program.

1424
01:17:15,840 --> 01:17:19,240
They open too many threads at once and end up creating a second coordination mess while

1425
01:17:19,240 --> 01:17:20,800
trying to fix the first one.

1426
01:17:20,800 --> 01:17:23,540
The intent is good but the design is fundamentally wrong.

1427
01:17:23,540 --> 01:17:25,440
You do not start by trying to fix everything.

1428
01:17:25,440 --> 01:17:28,520
Instead you start with one single process that gives you a clear signal.

1429
01:17:28,520 --> 01:17:32,440
That process needs to sit in a very specific zone where you have high friction and high volume

1430
01:17:32,440 --> 01:17:34,400
but only low to medium complexity.

1431
01:17:34,400 --> 01:17:38,040
It should already be painful enough that nobody will argue about whether it actually

1432
01:17:38,040 --> 01:17:39,040
matters.

1433
01:17:39,040 --> 01:17:42,240
You want something visible and repeatable that stays close enough to the business so people

1434
01:17:42,240 --> 01:17:44,160
can feel the improvement quickly.

1435
01:17:44,160 --> 01:17:48,840
Approval chains, request intake or status tracking are usually better first candidates than

1436
01:17:48,840 --> 01:17:50,560
large enterprise redesigns.

1437
01:17:50,560 --> 01:17:55,000
These smaller processes expose architecture problems clearly without demanding a full

1438
01:17:55,000 --> 01:17:57,400
rewrite of your operating model on day one.

1439
01:17:57,400 --> 01:18:00,320
Now let's map that logic back to the contoso example.

1440
01:18:00,320 --> 01:18:04,360
The procurement approval path worked well as a first move, not because procurement is

1441
01:18:04,360 --> 01:18:07,160
magical but because it met the right structural conditions.

1442
01:18:07,160 --> 01:18:12,000
The demand was frequent, the pain was visible and the logic was easy for everyone to understand.

1443
01:18:12,000 --> 01:18:15,720
All the failure signals were already there in the form of long cycle times, constant rework

1444
01:18:15,720 --> 01:18:17,080
and weak audit trails.

1445
01:18:17,080 --> 01:18:20,500
This gave the business a clean place to test the govern tree design without pretending

1446
01:18:20,500 --> 01:18:23,040
they had to solve every broken process at once.

1447
01:18:23,040 --> 01:18:24,040
That distinction matters.

1448
01:18:24,040 --> 01:18:28,640
If the first use case you pick is too large, too political or too ambiguous.

1449
01:18:28,640 --> 01:18:32,240
The organization will learn the wrong lesson from a difficult start.

1450
01:18:32,240 --> 01:18:35,600
People will confuse poor scoping with a weakness in the platform itself.

1451
01:18:35,600 --> 01:18:38,880
To avoid that I would keep your entry criteria very tight.

1452
01:18:38,880 --> 01:18:42,920
Pick one process where the volume is regular enough to measure and the pain is already accepted

1453
01:18:42,920 --> 01:18:44,040
as a reality.

1454
01:18:44,040 --> 01:18:48,200
You also need to make sure the ownership can be named clearly and the data boundaries

1455
01:18:48,200 --> 01:18:49,640
stays manageable.

1456
01:18:49,640 --> 01:18:52,840
Most importantly the result must be visible inside 90 days.

1457
01:18:52,840 --> 01:18:56,880
That last part is vital because the first build should do more than just improve the work.

1458
01:18:56,880 --> 01:19:00,120
It needs to teach the company how government improvement actually feels.

1459
01:19:00,120 --> 01:19:04,440
If the business has to wait a year to understand whether the new model works, old habits will

1460
01:19:04,440 --> 01:19:06,520
simply rush back into filter gap.

1461
01:19:06,520 --> 01:19:09,720
Before you build anything you need to baseline three specific things.

1462
01:19:09,720 --> 01:19:10,920
First look at cycle time.

1463
01:19:10,920 --> 01:19:14,840
You need to know how long the process actually takes from submission to completion in a

1464
01:19:14,840 --> 01:19:17,480
lab's business reality, not just in theory.

1465
01:19:17,480 --> 01:19:19,040
Second measure the rework rate.

1466
01:19:19,040 --> 01:19:22,960
Find out how often the same request gets corrected, resent or reject because the state of

1467
01:19:22,960 --> 01:19:24,440
the data was weak the first time.

1468
01:19:24,440 --> 01:19:26,120
Third look at the audit pain.

1469
01:19:26,120 --> 01:19:31,760
Note how often different teams disagree on status, numbers or who actually owns the evidence.

1470
01:19:31,760 --> 01:19:36,640
Those three signals give you a before state that carries real executive relevance.

1471
01:19:36,640 --> 01:19:41,680
They also stop the project from drifting into those vague empty claims about modernization.

1472
01:19:41,680 --> 01:19:43,120
You aren't trying to look more digital.

1473
01:19:43,120 --> 01:19:46,040
You're trying to remove measurable architectural waste.

1474
01:19:46,040 --> 01:19:49,080
To keep things on track you must keep the delivery model disciplined.

1475
01:19:49,080 --> 01:19:52,360
You need one owner, one governed environment and one success dashboard.

1476
01:19:52,360 --> 01:19:53,360
That is enough.

1477
01:19:53,360 --> 01:19:57,120
You don't need five parallel pilots or a broad invitation for everyone to start building

1478
01:19:57,120 --> 01:19:58,120
at once.

1479
01:19:58,120 --> 01:20:02,360
And one contained use case with clear responsibility and visible metrics.

1480
01:20:02,360 --> 01:20:06,560
While that first use case goes live, pay attention to something most teams completely miss.

1481
01:20:06,560 --> 01:20:09,520
Do not just admire the solution but make sure you capture the pattern.

1482
01:20:09,520 --> 01:20:13,840
Look at what intake fields were required and what rooting logic proved to be reusable.

1483
01:20:13,840 --> 01:20:18,400
Figure out which naming conventions and review steps worked so you can turn them into a template

1484
01:20:18,400 --> 01:20:19,880
for the next exception path.

1485
01:20:19,880 --> 01:20:23,720
The first build should become a repeatable design asset rather than a one off success story

1486
01:20:23,720 --> 01:20:27,040
that people celebrate and then quietly fail to reuse.

1487
01:20:27,040 --> 01:20:29,200
That is how you begin to scale safely.

1488
01:20:29,200 --> 01:20:33,200
You prove one lane works and then you make that lane easier for the next person to walk.

1489
01:20:33,200 --> 01:20:36,400
If you are wondering where to begin, my answer is plain.

1490
01:20:36,400 --> 01:20:39,160
Do not start with the biggest transformation you can find.

1491
01:20:39,160 --> 01:20:40,480
Start with the clearest friction.

1492
01:20:40,480 --> 01:20:44,480
Choose one process that already hurts, measure it honestly and rebuild it inside a governed

1493
01:20:44,480 --> 01:20:45,480
boundary.

1494
01:20:45,480 --> 01:20:48,320
Treat that result as the first pattern in a much larger operating model.

1495
01:20:48,320 --> 01:20:51,600
When the architecture improves in one visible place, the company finally gets evidence

1496
01:20:51,600 --> 01:20:54,160
that better flow is possible without losing control.

1497
01:20:54,160 --> 01:20:57,960
Once that happens, the next step is no longer just another isolated fix.

1498
01:20:57,960 --> 01:21:02,360
It becomes a new way to run your entire delivery system.

1499
01:21:02,360 --> 01:21:04,720
The operating model leaders should adopt next.

1500
01:21:04,720 --> 01:21:09,400
If we pull all of this together, the operating model leaders need next is not led by apps.

1501
01:21:09,400 --> 01:21:12,560
It is governance led, process owned and platform enabled.

1502
01:21:12,560 --> 01:21:16,960
That distinction is important because too many organizations still sponsor individual solutions

1503
01:21:16,960 --> 01:21:20,840
instead of sponsoring the conditions that led good solutions repeat.

1504
01:21:20,840 --> 01:21:26,520
One app will not fix the invisible company and one automation will not fix hidden coordination.

1505
01:21:26,520 --> 01:21:30,800
One dashboard will never restore trust if the operating model underneath it still depends

1506
01:21:30,800 --> 01:21:34,080
on scattered ownership and reactive delivery.

1507
01:21:34,080 --> 01:21:37,880
Leadership has to sponsor the model itself and that starts with the executive role.

1508
01:21:37,880 --> 01:21:41,920
Executives should not spend their energy choosing which small app gets attention next.

1509
01:21:41,920 --> 01:21:45,720
Their real job is to back the governance stance, fund the platform conditions and make

1510
01:21:45,720 --> 01:21:49,240
it clear that business led improvement must happen inside visible rules.

1511
01:21:49,240 --> 01:21:52,880
If leadership only funds isolated wins, the company just gets pockets of improvement.

1512
01:21:52,880 --> 01:21:56,740
If leadership funds the model, the company gets a compounding capability that grows over

1513
01:21:56,740 --> 01:21:57,740
time.

1514
01:21:57,740 --> 01:22:01,280
In this new world, IT has a different job than it had in the old central queue model.

1515
01:22:01,280 --> 01:22:03,080
IT should own the guardrails.

1516
01:22:03,080 --> 01:22:07,620
This means they handle identity, environment strategy, life cycle control and connector

1517
01:22:07,620 --> 01:22:08,620
policies.

1518
01:22:08,620 --> 01:22:10,480
They set the standards and the support parts.

1519
01:22:10,480 --> 01:22:12,000
That is real ownership.

1520
01:22:12,000 --> 01:22:15,320
But it is not ownership of every single process decision.

1521
01:22:15,320 --> 01:22:19,040
IT keeps the platform trustworthy but they do not need to remain the author of every

1522
01:22:19,040 --> 01:22:20,040
local fix.

1523
01:22:20,040 --> 01:22:21,760
The business role changes as well.

1524
01:22:21,760 --> 01:22:26,680
Business teams need to own the process logic, the outcome and the priority for improvement.

1525
01:22:26,680 --> 01:22:30,320
They are the ones who know where the friction sits and where the hand of break.

1526
01:22:30,320 --> 01:22:34,760
They know which approvals create useless noise and which exceptions keep repeating.

1527
01:22:34,760 --> 01:22:38,840
If they stay outside of solution ownership, the architecture will eventually drift away

1528
01:22:38,840 --> 01:22:40,280
from the real work again.

1529
01:22:40,280 --> 01:22:42,520
The operating model becomes a true partnership.

1530
01:22:42,520 --> 01:22:46,760
The business owns the problem while IT owns the platform conditions and security shapes

1531
01:22:46,760 --> 01:22:47,760
the boundaries.

1532
01:22:47,760 --> 01:22:51,320
The center of excellence connects those layers so delivery does not collapse back into

1533
01:22:51,320 --> 01:22:52,800
the politics of handoffs.

1534
01:22:52,800 --> 01:22:54,920
This is why fusion team logic matters here.

1535
01:22:54,920 --> 01:22:58,200
It isn't just a trend word, it is a practical correction.

1536
01:22:58,200 --> 01:23:02,160
When domain knowledge and platform discipline work together early, the business gets faster

1537
01:23:02,160 --> 01:23:05,440
solutions that actually survive contact with reality.

1538
01:23:05,440 --> 01:23:09,840
When they work separately, one side creates theory and the other creates workarounds.

1539
01:23:09,840 --> 01:23:13,600
If you want to know whether your operating model is working, do not start by counting

1540
01:23:13,600 --> 01:23:17,880
the number of apps you've built. Look for different signs, look for less waiting, less

1541
01:23:17,880 --> 01:23:20,080
rework and more trust in the numbers.

1542
01:23:20,080 --> 01:23:24,240
You should see fewer heroic individuals carrying an undocumented process load.

1543
01:23:24,240 --> 01:23:25,240
That is the real shift.

1544
01:23:25,240 --> 01:23:29,120
The company stops depending on structural compensation from exhausted people and starts

1545
01:23:29,120 --> 01:23:32,080
getting structural resilience from a better architecture.

1546
01:23:32,080 --> 01:23:36,400
If you look closely, the real move here is not from Excel to the power platform.

1547
01:23:36,400 --> 01:23:39,160
It is a move from invisible dependency to govern flow.

1548
01:23:39,160 --> 01:23:42,640
Once leaders understand that they stop asking what tool they should roll out next, they

1549
01:23:42,640 --> 01:23:47,240
start asking the better question, what operating model lets this business improve without rebuilding

1550
01:23:47,240 --> 01:23:51,840
fragility every single quarter that if you audited your process architecture the same way

1551
01:23:51,840 --> 01:23:56,400
you audit your systems, you would likely find a business running on invisible dependencies

1552
01:23:56,400 --> 01:23:58,840
and trust held together by memory.

1553
01:23:58,840 --> 01:24:02,760
This isn't a personal failing of your team, but rather a system outcome of how we've

1554
01:24:02,760 --> 01:24:04,680
built our workflows over time.

1555
01:24:04,680 --> 01:24:08,680
If this gave you a clearer frame for what Excel is actually doing inside your company,

1556
01:24:08,680 --> 01:24:12,680
leave a review for the podcast and connect with me, Mirko Peters on LinkedIn, send me the

1557
01:24:12,680 --> 01:24:16,360
next topic you want me to break down and let's figure out if your systems are designed

1558
01:24:16,360 --> 01:24:18,320
to sustain you or slowly drain you.