<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[CoreLab FlowTrack]]></title>
  <link>https://corelabflowtrack.com/</link>
  <description><![CDATA[CoreLab FlowTrack offers process consulting and workflow redesign for mid-size organisations. Based in Nottingham. Measurable results, 90-day implementation support.]]></description>
  <language>en</language>
  <atom:link href="https://corelabflowtrack.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[Why Your Process Map Is Probably Wrong Before You Start]]></title>
    <link>https://corelabflowtrack.com/</link>
    <description><![CDATA[Most process maps are drawn from memory in a meeting room. They show how the workflow is supposed to run, not how it actually runs. The gap between those two things is usually where the time goes. Here is what we do instead.]]></description>
    <pubDate>2026-06-30</pubDate>
  </item>
  <item>
    <title><![CDATA[The 90-Day Rule: Why Process Changes Fail After the Consultant Leaves]]></title>
    <link>https://corelabflowtrack.com/</link>
    <description><![CDATA[A new process design is not a finished product. It is a hypothesis. The real work begins when the team starts running it, and that is exactly when most consulting engagements end. We built our model around staying through that period.]]></description>
    <pubDate>2026-05-14</pubDate>
  </item>
  <item>
    <title><![CDATA[How to Map a Business Process Without Getting It Wrong]]></title>
    <link>https://corelabflowtrack.com/notes/how-to-map-a-business-process-accurately.html</link>
    <guid>https://corelabflowtrack.com/notes/how-to-map-a-business-process-accurately.html</guid>
    <description><![CDATA[Process mapping sounds straightforward until you try to do it accurately. Most organisations have process maps. Most of those maps describe the intended process, not the actual one. The difference between those two things is usually measured in hours of lost time per week, and it is almost always where the improvement opportunity is hiding.]]></description>
    <pubDate>2026-05-20</pubDate>
  </item>
  <item>
    <title><![CDATA[Reducing Cycle Time: What Actually Works in Practice]]></title>
    <link>https://corelabflowtrack.com/notes/cycle-time-reduction-practical-guide.html</link>
    <guid>https://corelabflowtrack.com/notes/cycle-time-reduction-practical-guide.html</guid>
    <description><![CDATA[Cycle time reduction is one of the most requested outcomes in process consulting. It is also one of the most misunderstood. The assumption is usually that the process needs to be speeded up. In most cases, the process does not need to be speeded up. It needs to have the waiting removed from it.]]></description>
    <pubDate>2026-04-10</pubDate>
  </item>
  <item>
    <title><![CDATA[When Is a Business Process Actually Ready to Automate?]]></title>
    <link>https://corelabflowtrack.com/notes/when-to-automate-a-business-process.html</link>
    <guid>https://corelabflowtrack.com/notes/when-to-automate-a-business-process.html</guid>
    <description><![CDATA[The business case for workflow automation is usually presented in terms of time saved and errors reduced. Those benefits are real, but they depend on a condition that is rarely stated explicitly: the process being automated needs to be stable, well-documented, and free of informal exception-handling steps that cannot be encoded in a rule set. When that condition is not met, automation creates new problems rather than solving existing ones.]]></description>
    <pubDate>2026-03-05</pubDate>
  </item>
  <item>
    <title><![CDATA[Change Management for Operations Managers: A Practical View]]></title>
    <link>https://corelabflowtrack.com/notes/change-management-for-operations-managers.html</link>
    <guid>https://corelabflowtrack.com/notes/change-management-for-operations-managers.html</guid>
    <description><![CDATA[Process redesign projects fail at implementation more often than they fail at design. The future-state process is usually sound. The problem is that the people who need to run it were not sufficiently involved in designing it, do not fully understand why it is different from the old one, or have legitimate concerns about the change that were not addressed before go-live. Change management is the work of preventing those outcomes.]]></description>
    <pubDate>2026-02-01</pubDate>
  </item>
  <item>
    <title><![CDATA[Why You Need a Process Audit Twelve Weeks After Go-Live]]></title>
    <link>https://corelabflowtrack.com/notes/process-audit-twelve-weeks-after-go-live.html</link>
    <guid>https://corelabflowtrack.com/notes/process-audit-twelve-weeks-after-go-live.html</guid>
    <description><![CDATA[Process improvements have a half-life. The gains achieved in the first weeks after a redesign go-live are real, but they are not self-sustaining. Without a structured review at a defined point after implementation, most organisations find that performance has drifted back toward the old baseline within three to six months. The drift is usually gradual and not immediately visible in headline metrics.]]></description>
    <pubDate>2026-01-15</pubDate>
  </item>
</channel>
</rss>
