Down­load the full inter­view here.

When an SAP trans­for­ma­tion starts show­ing cracks, Kim Snow is often one of the first calls orga­ni­za­tions make. As Senior Vice Pres­i­dent at Bay­force, a bou­tique con­sult­ing firm where she’s spent near­ly three decades, Snow has watched count­less large-scale pro­grams veer off course when time­lines slip, scope bal­loons, and some­where along the way, the busi­ness real­izes it hand­ed over too much con­trol to an out­side part­ner.

Bay­force occu­pies a dis­tinct space in the SAP ecosys­tem. The firm doesn’t try to own entire trans­for­ma­tion pro­grams the way large sys­tems inte­gra­tors do. Instead, it deploys senior con­sul­tants to fill gaps, sta­bi­lize trou­bled ini­tia­tives, or sup­port orga­ni­za­tions that want to run their own projects. It’s a mod­el built on a sim­ple premise: the cus­tomer should stay in the driver’s seat.

Snow, who man­ages the company’s ERP and cloud solu­tions and ser­vices, brings an operator’s per­spec­tive to ques­tions about SAP pro­gram deliv­ery. She has over­seen teams of more than 200 con­sul­tants across the U.S. and Cana­da, built exec­u­tive rela­tion­ships with clients nav­i­gat­ing high-stakes tech­nol­o­gy invest­ments, and shaped the deliv­ery and recruit­ing process­es that under­pin Bayforce’s model.

In a con­ver­sa­tion with ASUG, Snow can­did­ly dis­cussed how to spot a pro­gram that’s stalling, the over­looked gaps that derail even well-resourced ini­tia­tives, and why lead­ers shouldn’t be afraid to push back or chart their own course.

This inter­view has been edit­ed and con­densed for length and clarity.

Q: At a high lev­el, what are some of the key chal­lenges you see orga­ni­za­tions nav­i­gat­ing in today’s busi­ness envi­ron­ment as they approach com­plex, large-scale SAP trans­for­ma­tion programs?

Large-scale SAP trans­for­ma­tions today are rarely just an IT upgrade. They’re major busi­ness deci­sions. Orga­ni­za­tions have to sort through big choic­es right away, like whether to move quick­ly with a brown­field con­ver­sion or use a green­field approach to clean up years of cus­tomiza­tion and tech­ni­cal debt. They also have to decide on the right deliv­ery mod­el, whether that’s part­ner­ing with a sys­tems inte­gra­tor, build­ing inter­nal exper­tise, or some­thing in between.

At the same time, lead­ers are under pres­sure to make a clear case for ROI. Even with new AI capa­bil­i­ties in SAP that promise effi­cien­cy gains, it can still be tough to trans­late those into hard num­bers. All of this means that suc­cess depends less on the tech­nol­o­gy itself and more on align­ment, plan­ning, and keep­ing the busi­ness engaged through­out the journey.

Q: Often, such orga­ni­za­tions will turn to large sys­tems inte­gra­tors to sup­port trans­for­ma­tion jour­neys — but that doesn’t always guar­an­tee projects, espe­cial­ly com­plex SAP pro­grams, will be deliv­ered on-time or on-bud­get. In your expe­ri­ence, what kinds of pit­falls do orga­ni­za­tions expe­ri­ence when they rely too much on large SI partners?

Large sys­tems inte­gra­tors can play an impor­tant role in big SAP pro­grams, but rely­ing on them too heav­i­ly often cre­ates blind spots. One of the biggest pit­falls I see is when orga­ni­za­tions assume the SI will ​“own” the trans­for­ma­tion end-to-end. That can lead to a loss of inter­nal con­trol and over­sight. If the busi­ness isn’t active­ly engaged in defin­ing out­comes, mak­ing deci­sions, and chal­leng­ing assump­tions, then pro­grams tend to drift, and that’s when time­lines and bud­gets slip.

Anoth­er issue is that SI teams don’t always bring the indus­try con­text need­ed to make the right design deci­sions. Strong tech­ni­cal skills alone aren’t enough, and when design hap­pens in a vac­u­um, rework becomes inevitable. We also see resourc­ing chal­lenges: teams that are too junior, high turnover, or con­sul­tants who are learn­ing on the job, all of which slow the pro­gram down. This is espe­cial­ly true for more niche SAP skill areas where the large SIs strug­gle to deliv­er strong consultants.

And final­ly, there are often crit­i­cal areas the SI doesn’t tru­ly own, things like data cleans­ing and migra­tion, change man­age­ment, report­ing, end-user train­ing, and go-live sup­port. When those gaps aren’t cov­ered, they can quick­ly put the entire time­line at risk. At the end of the day, SIs are look­ing out for their own best inter­ests, not yours, which is why orga­ni­za­tions need to make sure they have the right exper­tise and account­abil­i­ty mod­el in place.

Q: Bay­force spe­cial­izes in sup­port­ing orga­ni­za­tions at crit­i­cal pro­gram junc­tures. In what kinds of sce­nar­ios do orga­ni­za­tions typ­i­cal­ly approach you, and what makes Bay­force unique for orga­ni­za­tions in the SAP ecosystem?

Orga­ni­za­tions typ­i­cal­ly come to Bay­force at a few crit­i­cal moments in their SAP jour­ney. Some­times they approach us instead of hir­ing a large SI alto­geth­er because they already have strong inter­nal SAP capa­bil­i­ties and want to tru­ly own their project. In those cas­es, we pro­vide senior func­tion­al experts and/​or SAP project lead­er­ship where we have shared respon­si­bil­i­ty for the project, but the orga­ni­za­tion stays in control.

Oth­er times, com­pa­nies bring us in after they’ve already engaged an SI but start see­ing the clas­sic warn­ing signs: time­lines slip­ping, scope creep­ing, design con­cerns, or an SI team that’s too junior for what the pro­gram real­ly requires. We might step in to pro­vide QA over­sight, rein­force a spe­cif­ic work­stream, or sup­ply indus­try spe­cial­ists where the SI’s exper­tise isn’t deep enough. We can also quick­ly deliv­er niche SAP con­sul­tants that the SIs often can’t because they don’t have some­one avail­able with those skill sets.

What makes Bay­force unique is that we can deliv­er plat­inum-lev­el SAP con­sult­ing tal­ent at a much low­er cost than the large inte­gra­tors, and we’re gen­uine­ly com­fort­able tak­ing on the roles that big SIs don’t want, whether that’s gap cov­er­age, tar­get­ed exper­tise, or sup­port­ing a cus­tomer-led mod­el. We embed an Engage­ment Man­ag­er and Con­sul­tant Rela­tion­ship Man­ag­er and are active­ly engaged in the project’s suc­cess, but we’re not try­ing to ​“own” the project; we’re there to make sure the cus­tomer retains con­trol, gets the right exper­tise at the right time, and ulti­mate­ly deliv­ers a suc­cess­ful pro­gram. We also let our cus­tomers con­vert our con­sul­tants to retain that knowl­edge in-house.

Q: When you’re asked to sup­port a pro­gram that’s already under­way, what kinds of warn­ing signs, con­di­tions, or pat­terns usu­al­ly indi­cate that a client needs addi­tion­al exper­tise or a dif­fer­ent type of deliv­ery support?

By the time orga­ni­za­tions call us, there’s usu­al­ly a sense that the pro­gram has lost trac­tion — mile­stones aren’t lin­ing up, deci­sions are get­ting bot­tle­necked, or the design isn’t hold­ing togeth­er the way it should. We also see symp­toms like unclear own­er­ship, incon­sis­tent qual­i­ty across work­streams, or busi­ness teams feel­ing dis­con­nect­ed from the project.

Q: Step­ping into com­plex ini­tia­tives, what steps do your experts take to assess a client’s pain points and set pri­or­i­ties for the ear­ly phase of your engage­ment? How do you work to quick­ly regain stake­hold­er trust in these scenarios?

When we step into a com­plex pro­gram, our first pri­or­i­ty is to quick­ly under­stand what’s real­ly hap­pen­ing beneath the sur­face. We start with a focused assess­ment of the areas that typ­i­cal­ly cre­ate the most fric­tion, such as gov­er­nance, design deci­sions, resourc­ing, data readi­ness, and how close­ly the busi­ness is con­nect­ed to the pro­gram. From there, we iden­ti­fy the true bot­tle­necks, clar­i­fy own­er­ship, and set a short list of pri­or­i­ties that will sta­bi­lize the pro­gram fastest.

Con­nect with Kim Snow on LinkedIn.

To rebuild stake­hold­er trust, we’re very trans­par­ent about what we’re see­ing and what needs to hap­pen next. Our senior experts engage direct­ly with busi­ness and IT lead­ers, reset expec­ta­tions, and estab­lish a cadence of com­mu­ni­ca­tion that gives every­one con­fi­dence that the pro­gram is back under con­trol. Show­ing progress quick­ly, clos­ing gaps, improv­ing qual­i­ty, and bring­ing clar­i­ty to deci­sions goes a long way in help­ing teams feel aligned, sup­port­ed, and reenergized.

Q: Bay­force is often engaged to pro­vide focused, senior-lev­el sup­port on major pro­grams. How does that approach influ­ence the way you struc­ture your teams and col­lab­o­rate with client stake­hold­ers, and what bal­ance do you seek to strike between pro­vid­ing spe­cial­ized experts and build­ing SAP skills or capa­bil­i­ties with­in client organizations?

Because we’re typ­i­cal­ly brought in to pro­vide senior-lev­el, spe­cial­ized exper­tise, we struc­ture our teams to be high­ly expe­ri­enced, hands-on, and tight­ly inte­grat­ed with the client’s own peo­ple. Our goal is always to work our­selves out of a job. That means knowl­edge trans­fer, doc­u­men­ta­tion, and train­ing aren’t after­thoughts; they’re built into how we work from day one.

We also take a very col­lab­o­ra­tive approach with stake­hold­ers, so the client’s team is learn­ing along­side our experts, not watch­ing from the side­lines. And when it makes sense for both par­ties, we even allow clients to con­vert our con­sul­tants at no addi­tion­al cost so they can retain that exper­tise in-house long after go-live.

Q: For orga­ni­za­tions that have estab­lished a glob­al tem­plate for an SAP pro­gram, what key con­sid­er­a­tions could con­ceiv­ably be over­looked dur­ing roll­out and adoption?

Even with a strong glob­al tem­plate, orga­ni­za­tions often over­look how much region­al vari­a­tion needs to be addressed dur­ing roll­out. Local reg­u­la­tions, tax require­ments, process nuances, and report­ing needs can expose gaps that weren’t vis­i­ble at the glob­al design lev­el. Change man­age­ment is anoth­er com­mon blind spot — train­ing, com­mu­ni­ca­tion, and sup­port must be tai­lored to each region or adop­tion suffers.

Last­ly, teams some­times assume data, inte­gra­tions, and gov­er­nance will scale glob­al­ly with­out val­i­dat­ing that ear­ly. Those issues tend to show up late, right when the project is try­ing to go live.

Q: Large SAP pro­grams accu­mu­late scope and com­plex­i­ty quick­ly. In your expe­ri­ence, what prac­tices help keep these ini­tia­tives dis­ci­plined, effi­cient, and cen­tered on the out­comes that mat­ter most?

The best way to keep large SAP pro­grams dis­ci­plined is to get very clear up front about what’s tru­ly required for go-live ver­sus what can wait for a lat­er phase. When teams dis­tin­guish must-haves from nice-to-haves ear­ly, it pre­vents scope creep and keeps every­one focused on the out­comes that mat­ter most.

Vis­it the Bay­force web­site. 

It also requires a mind­set shift. Busi­ness and IT need to see the pro­gram as an oppor­tu­ni­ty to rethink process­es, not repli­cate every lega­cy workaround. If a stan­dard best-prac­tice approach will meet the need, that should be the default; cus­tomiza­tions add cost, risk, and long-term com­plex­i­ty. Strong change man­age­ment from day one helps rein­force this think­ing and encour­ages teams to sim­pli­fy, chal­lenge assump­tions, and design for the future rather than the past.

Q: Look­ing across the trans­for­ma­tions you’ve sup­port­ed, what guid­ance would you offer lead­ers who want to man­age risk effec­tive­ly, main­tain stake­hold­er trust, and main­tain momen­tum through­out mul­ti-year SAP roadmaps?

For lead­ers nav­i­gat­ing mul­ti-year SAP roadmaps, the biggest advice I can give is to stay active­ly engaged and not be afraid to take a non-tra­di­tion­al path when it’s in the organization’s best inter­est. Some of the most suc­cess­ful pro­grams I’ve seen are the ones where the busi­ness isn’t afraid to man­age more of the project them­selves, chal­lenge assump­tions, or push back when an SI’s approach doesn’t feel right.

Main­tain­ing stake­hold­er trust comes from trans­paren­cy and clar­i­ty, being clear about pri­or­i­ties, hon­est about what’s work­ing or not, and ground­ing deci­sions in the out­comes that tru­ly mat­ter. And when ear­ly warn­ing signs appear, lead­ers shouldn’t hes­i­tate to bring in addi­tion­al exper­tise or fresh eyes. Some­times, tar­get­ed out­side sup­port can sta­bi­lize a pro­gram faster than forc­ing a strug­gling mod­el to keep going.

Ulti­mate­ly, lead­ers who stay hands-on, stay curi­ous, and stay open to dif­fer­ent deliv­ery approach­es are the ones who keep their pro­grams aligned, resilient, and mov­ing for­ward over the long haul.

Q: Con­trol­ling costs and pre­vent­ing project ​“bloat” is essen­tial. One of the biggest pain points ASUG mem­bers con­sis­tent­ly report in nav­i­gat­ing dig­i­tal trans­for­ma­tion per­tains to bud­get; how does Bay­force ingrain cost effi­cien­cy into your engage­ment with customers?

Cost effi­cien­cy is built direct­ly into the way we work. The beau­ty of part­ner­ing with Bay­force is that our cus­tomers get some of the most expe­ri­enced SAP con­sul­tants in the indus­try at near­ly half the rate they’re pay­ing large SIs. Because we don’t car­ry the over­head, lay­ers of man­age­ment, or inter­nal bloat that big firms do, we’re able to pay our con­sul­tants more, charge our cus­tomers less, and still deliv­er top-tier expertise.

Because we’re com­fort­able sup­port­ing tar­get­ed work­streams or cus­tomer-led mod­els, we help orga­ni­za­tions avoid unnec­es­sary spend on ser­vices they don’t need. Our entire approach is designed to max­i­mize val­ue and min­i­mize waste from day one.